[mono] Fix class initialization spurious wakeups #96903
Conversation
the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning. Fixes dotnet#96872
if we goto retry_top, don't set up a new handle frame that lacks a matching HANDLE_FUNCTION_RETURN_VAL. Instead setup the handle frame once upfront
ghost
assigned 
|
@lambdageek I think it also fixes this one right? |
yes. same issue. |
|
/azp run runtime-extra-platforms |
|
/backport to release/8.0-staging |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/7505359031 |
|
All failures are known |
|
@lambdageek , Is this change (#96903) available on a daily build. I am seeing the same issue ("Assertion at /__w/1/s/src/mono/mono/metadata/object.c:657, condition `lock->done' not met") after updating to dotnet 8.0.100. Tried the "8.0.200-preview.24064.2" and that didn't have the fix either(crashes) . |
the |
* mono_runtime_class_init_full: handle spurious wakeups the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning. Fixes dotnet#96872 and dotnet#96804 * fix unbalanced handle frames if we goto retry_top, don't set up a new handle frame that lacks a matching HANDLE_FUNCTION_RETURN_VAL. Instead setup the handle frame once upfront
mono_runtime_class_init_full: handle spurious wakeups.the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning.
Fixes [monovm] Assertion at object.c:657, condition `lock->done' not met #96872 and [Android][Regression] * Assertion at /__w/1/s/src/mono/mono/metadata/object.c:657, condition `lock->done' not met #96804
fix unbalanced handle frames.
if we goto retry_top, don't set up a new handle frame that lacks a matching HANDLE_FUNCTION_RETURN_VAL.
Instead setup the handle frame once upfront