You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MacOS arm64 NAOT runtime-async - bad ResumeInfo written (causing failure on StackTraceTests) #124015
No; what happens is when we return from Foo2 into Foo1, and attempt to run the resumption of Foo1 (which should be the catch handler because Foo2 throws an exception in its finally), the ResumeInfo contains bad addresses (not sure exactly what is in there, but it looks like some flags on the high bits). We set a watchpoint on the second Continuation created for Foo1, and see that the bad data is written shortly before a call to CaptureContinuationContext, and after some adrp arithmetic. The calling of a bad address in DispatchContinuations then surfaces as the UnmanagedCallersOnly error.
Interestingly only the second adrp/add pair is corrupted in the function in the executable. I'm guessing this is some object writer bug. I can reproduce the issue locally in the object file produced by ILC: only the second adrp/add pair looks wrong there too.
It looks like we are not running runtime tests for osx-arm64 in nativeaot-outerloop, otherwise I expect we would have seen the normal async tests failing in #123433.
Activity
dotnet-policy-service commentedon Feb 4, 2026
Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.
jakobbotsch commentedon Feb 4, 2026
Is the
in the log unrelated?
rcj1 commentedon Feb 4, 2026
No; what happens is when we return from Foo2 into Foo1, and attempt to run the resumption of Foo1 (which should be the catch handler because Foo2 throws an exception in its
finally), the ResumeInfo contains bad addresses (not sure exactly what is in there, but it looks like some flags on the high bits). We set a watchpoint on the second Continuation created for Foo1, and see that the bad data is written shortly before a call to CaptureContinuationContext, and after someadrparithmetic. The calling of a bad address in DispatchContinuations then surfaces as the UnmanagedCallersOnly error.jakobbotsch commentedon Feb 5, 2026
Interestingly only the second
adrp/addpair is corrupted in the function in the executable. I'm guessing this is some object writer bug. I can reproduce the issue locally in the object file produced by ILC: only the secondadrp/addpair looks wrong there too.jakobbotsch commentedon Feb 5, 2026
This fixes the issue:
It is the equivalent of this code that I found in LLVM:
https://github.com/llvm/llvm-project/blob/3a084241248efd7d5259183cffae1d5b7057a54c/llvm/lib/Target/AArch64/MCTargetDesc/AArch64MachObjectWriter.cpp#L355-L382
@filipnavara does this look right?
filipnavara commentedon Feb 5, 2026
At first glance it does.
(I will have a second look tomorrow when I get back to my machine; already OOF today)
jakobbotsch commentedon Feb 5, 2026
It looks like we are not running runtime tests for osx-arm64 in nativeaot-outerloop, otherwise I expect we would have seen the normal async tests failing in #123433.
Fix MachO adrp/add and branch relocations with embedded addend (dotne…
Fix MachO adrp/add and branch relocations with embedded addend (dotne…