[mono][sgen] Fix initialization of can_reduce_color

[BrzVlad]

Mark it as true also in the case when the SCC contains bridge objects. Code populating other_colors for this SCC depends on it.

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/mono/mono/metadata/sgen-tarjan-bridge.c:749

• Ensure that there are unit tests covering both cases: when SCCs contain xrefs and when they contain bridge objects without xrefs, to verify that can_reduce_color is set correctly.

if (dyn_array_ptr_size (&other->xrefs) > 0 || found_bridge) {

[BrzVlad]

@filipnavara Vitek said that MAUI encountered this assertion after backport of #114391

Assertion at /w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:801, condition `can_reduce_color == FALSE' not met
      04-11 15:13:22.192  3831  3831 F monodroid: * Assertion at /w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:801, condition `can_reduce_color == FALSE' not met`

It looks like this could happen if the initial iteration over the loop stack encounters a bridge object early (so it doesn't set can_reduce_color to FALSE). Then, in the second iteration (after the node heaviness fix), we would assert when encountering a node with other->xrefs populated. cc @vitek-karas @jeffschwMSFT

[filipnavara]

Right, this is the correct fix, or changing the assert to g_assert (can_reduce_color == FALSE || found_bridge);.

Thanks!

[BrzVlad]

Added a new commit to disable running the test on wasm and mobile. Seems like on 9.0 runs it was failing, although no failures were spotted on main.