-
Notifications
You must be signed in to change notification settings - Fork 5.3k
[interp] Use existing InterpMethod if allocation and lookup race #57968
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
Conversation
If two threads both want to get an InterpMethod for the same MonoMethod, and they both see null from the first hash table lookup, make sure that whichever one comes into the jit_mm lock second re-uses the previously inserted InterpMethod, instead of its own version. Without this change, racing threads will overwrite MonoJitInfo:seq_points (in mono_interp_transform_method) which sometimes leads to deallocating the same sequence points multiple times. Fixes dotnet#57812
|
Tagging subscribers to this area: @BrzVlad Issue DetailsIf two threads both want to get an InterpMethod for the same MonoMethod, and they both see null from the first hash table lookup, make sure that whichever one comes into the jit_mm lock second re-uses the previously inserted InterpMethod, instead of its own version. Without this change, racing threads will overwrite MonoJitInfo:seq_points (in mono_interp_transform_method) which sometimes leads to deallocating the same sequence points multiple times. Fixes #57812
|
|
With this change running the test from #57812 in a loop doesn't lead to a crash after 20 minutes of runs. (before this change, I could get a crash in under a minute) |
|
I'm a little bit unclear on why this is enough to fix the double-free. It's something about the I would have expected that in runtime/src/mono/mono/mini/interp/transform.c Lines 9821 to 9845 in 331cfe3
|
|
/backport to release/6.0-rc1 |
|
Started backporting to release/6.0-rc1: https://github.com/dotnet/runtime/actions/runs/1160620455 |
If two threads both want to get an InterpMethod for the same MonoMethod, and they both see null from the first hash table lookup, make sure that whichever one comes into the jit_mm lock second re-uses the previously inserted InterpMethod, instead of its own version.
Without this change, racing threads will overwrite MonoJitInfo:seq_points (in mono_interp_transform_method) which sometimes leads to deallocating the same sequence points multiple times.
Fixes #57812