[mono] Fix for issue 109410 #113140
[mono] Fix for issue 109410 #113140
Conversation
There was a problem hiding this comment.
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
|
@BrzVlad noticed that we might need a memory barrier to prevent other threads from observing a We haven't seen this on x64, which makes sense because x86 and x64 have a stronger memory model, but I need to figure out whether this particular failure is possible with ARM's weaker memory model or not. |
Remove emitted nullcheck in jitcode (too expensive)
kg
changed the title
| @@ -6806,6 +6806,8 @@ mono_object_handle_isinst (MonoObjectHandle obj, MonoClass *klass, MonoError *er | |||
| { | |||
| error_init (error); | |||
|
|
|||
| g_assert (klass); | |||
There was a problem hiding this comment.
This assert is not particularly helpful, we will crash immediately at the line below anyway.
There was a problem hiding this comment.
on wasm we wouldn't, but i don't know if this code runs on wasm
| // we need a barrier before publishing data via mrgctx->infos [i] because the contents of data may not | ||
| // have been published to all cores and another thread may read zeroes or partially initialized data | ||
| // out of it, even though we have a barrier before publication of entries in mrgctx->entries below | ||
| mono_memory_barrier(); |
There was a problem hiding this comment.
Could an option be to use a local array in this loop and then do a memcpy into mrgctx->infos after the memory barrier we already fire below (where we copy entries)? That way we will only fire one memory barrier instead of info->num_entries.
Issue #109410 appears to be a case where klass is 0 when we perform an isinst operation, but the cache and obj are nonzero and look like valid addresses. klass is either a compile-time (well, jit-time) constant or being fetched out of the cache (it looks like it can be either depending on some sort of rgctx condition).
This PR adds null checks in two places along with a memory barrier in the location where we believe an uninitialized cache is being published to other threads.