[filipnavara]

Fixes: #13194

Context: #13065

When two threads load the same assembly from the assembly store for the
first time, both can enter the initialization block in
EmbeddedAssemblies::assembly_store_open_from_bundles() (MonoVM) and
AssemblyStore::open_assembly() (CoreCLR). That block wrote
image_data, descriptor and debug_info_data with plain stores, and
other threads checked image_data != nullptr with a plain load to decide
whether the entry was ready.

On weakly ordered CPUs such as arm64, those stores can become visible to
another core in any order, and the reader's later loads aren't ordered
after its image_data check. A second thread can therefore see
image_data set, skip initialization, and read descriptor->data_size
while descriptor is still NULL:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8
libmonodroid.so EmbeddedAssemblies::open_from_bundles(...)

The issue reports this from the field (about 3,200 users on
.NET for Android 36.1.69, Release, arm64). It was also reproduced
deterministically by stopping a thread under a debugger at the point
where it can see image_data set but not descriptor.

Fix: compute image_data, debug_info_data and the descriptor
(&store_entry) locally from the assembly store entry, and have the
loader use only those local values. It no longer reads them back from
the shared AssemblyStoreSingleAssemblyRuntimeData, so it can't race with
another thread that is still initializing the same entry. The shared
fields are still filled in: descriptor and debug_info_data with
relaxed atomic stores, then image_data last with __ATOMIC_RELEASE.
The readiness check reads image_data with __ATOMIC_ACQUIRE. In the
arm64 release build the check compiles to ldar and the publish to
stlr.

To support this, the MonoVM get_assembly_data() overload that took
the runtime data struct is removed (the existing pointer-and-size
overload is used instead). The CoreCLR get_assembly_data() now takes
the image pointer and size directly.

main isn't affected: the MonoVM host was removed in #12868, and #12972
changed CoreCLR to fill in this data while the assembly store is set up,
before any lookups can run.

This doesn't address #13065, which is a separate race in
map_runtime_file() on the individual-assembly (non-store) path.

There's no automated test: the race window is a few instructions wide
and depends on timing.

[Copilot]

🟡 Changes recommended

Both loaders still have plain field reads that can race with atomic writes from another in-flight initializer.

1 open issue

• Prevent data races during concurrent assembly entry initialization · New

What changed in this PR

This release-branch fix addresses assembly-store initialization races in MonoVM and CoreCLR reported in #13194. The separate non-store race in #13065 remains outside scope.

Changes:

• Store descriptor and debug-information pointers before publishing image_data.
• Use release/acquire operations to order publication and readiness checks in both loaders.

File	Description
src/​native/​mono/​monodroid/​embedded-assemblies.cc	Adds ordered publication to MonoVM assembly-store initialization.
src/​native/​clr/​host/​assembly-store.cc	Applies the same publication ordering to CoreCLR.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The revised loaders eliminate the shared-field reads responsible for the reported race, with no unresolved blocking findings.

No open issues 🎉

1 resolved since last review

• Prevent data races during concurrent assembly entry initialization

_{Review effort: Balanced}

[filipnavara]

Closing in favor of #13264 approach