-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NativeAot + Objective-C Marshal] memory corruption after thin locks were introduced #80031
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
See also #80032. Both proposed solutions cause the test to stop crashing, but I don't know if they fix the root cause. |
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsSpecifically while running the test in At this point I'm still investigating the cause of the corruption. Using Crash detailsThe crashing stack trace:
Within the virtual call stub at the top of the stack, a register that should be pointing at a vtable is pointing one byte past the vtable. Specifically it is pointing at:
Other thoughtsThis hash code related code path is being called while the program is paused in the garbage collector. It can potentially allocate memory or take locks, which is not allowed according to the rules of restricted callouts. I'll file a separate issue for that.
|
cc @VSadov |
The code is violating this rule: runtime/src/coreclr/nativeaot/Runtime/RestrictedCallouts.h Lines 17 to 18 in fa7d049
|
Ah, thanks for pointing out that rule. The reason the Thin Locks PR caused the test to start failing is it introduced a virtual call in RuntimeHelpers.GetNewHashCode. I'll close this issue and leave #80032 open to track fixing the problem. |
Also there is a possible allocation, which could try to trigger GC, while doing GC. |
Specifically while running the test in
src/tests/Interop/ObjectiveC/ObjectiveCMarshalAPI
, compiled using NativeAOT.At this point I'm still investigating the cause of the corruption. Using
git bisect
I determined the test started failing when thin locks, #79519, was merged. Another possibility is I made a mistake while implementing #78280.Crash details
The crashing stack trace:
Within the virtual call stub at the top of the stack, a register that should be pointing at a vtable is pointing one byte past the vtable. Specifically it is pointing at:
Other thoughts
This hash code related code path is being called while the program is paused in the garbage collector. It can potentially allocate memory or take locks, which is not allowed according to the rules of restricted callouts. I'll file a separate issue for that.
The text was updated successfully, but these errors were encountered: