[Android] .Net 10.0.102 random crash with SIGSEGV in major_copy_or_mark_object_concurrent_no_evacuation

[juwens]

Description

* thread #17, name = 'SGen worker', stop reason = breakpoint 2.1
  * frame #0: 0x0000007c70d3dfb8 libart.so`art_sigsegv_fault
    frame #1: 0x0000007c70d3db58 libart.so`art::FaultManager::HandleSigsegvFault(int, siginfo*, void*) - 18446743539240674471
    frame #2: 0x0000007f376a1c8c libsigchain.so`art::SignalChain::Handler(int, siginfo*, void*) + 372
    frame #3: 0x0000007f397d9860 [vdso]`__kernel_rt_sigreturn
    frame #4: 0x0000007bce39cfd4 libmonosgen-2.0.so`drain_gray_stack_concurrent [inlined] major_copy_or_mark_object_concurrent_no_evacuation(ptr=<unavailable>, obj=0x0000800000000000, queue=0x0000007f3778a010) at sgen-marksweep-drain-gray-stack.h:137:23
    frame #5: 0x0000007bce39cfd4 libmonosgen-2.0.so`drain_gray_stack_concurrent [inlined] major_scan_object_concurrent_no_evacuation(full_object=<unavailable>, desc=245957, queue=0x0000007f3778a010) at sgen-scan-object.h:59:3
    frame #6: 0x0000007bce39c27c libmonosgen-2.0.so`drain_gray_stack_concurrent [inlined] drain_gray_stack_concurrent_no_evacuation(queue=0x0000007f3778a010) at sgen-marksweep-drain-gray-stack.h:347:3
    frame #7: 0x0000007bce39c244 libmonosgen-2.0.so`drain_gray_stack_concurrent(queue=0x0000007f3778a010) at sgen-marksweep.c:1312:10
    frame #8: 0x0000007bce3ba510 libmonosgen-2.0.so`marker_idle_func(data_untyped=0x0000007f3778a008) at sgen-workers.c:363:3
    frame #9: 0x0000007bce3b9570 libmonosgen-2.0.so`thread_func(data=0x0000000000000000) at sgen-thread-pool.c:219:5
    frame #10: 0x0000007f2a093d00 libc.so`__pthread_start(void*) (.__uniq.67847048707805468364044055584648682506) + 240
    frame #11: 0x0000007f2a086504 libc.so`__start_thread + 68

Reproduction Steps

At random places in our internal LOB app.

Expected behavior

App should not crash randomly with a SIGSEGV in sgen.

Actual behavior

App crashes randomly with a SIGSEGV in sgen.

Regression?

Not sure. We've seen SIGSEGV crashes .Net 8 too, but didn't pus as much analysis into differentiating them. Some of the SIGSEGV in .Net were caused by the implicit-null-checks and we fixed them by MONO_DEBUG=explicit-null-checks. But this SIGSEGV crash has obliviously a different source.

Known Workarounds

none

Configuration

• .Net 10.0.102
• Android 16
• ARM64
• Pixel 7a

Other information

No response

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Maui Android runtime crash - major_copy_or_mark_object_concurrent_no_evacuation #116542

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[BrzVlad]

Does using the non-concurrent major collector have any impact on the crashes ? MONO_GC_PARAMS=major=marksweep

[BrzVlad]

Other things worth trying out, aside from the major=marksweep option from above:

• MONO_GC_PARAMS=disable-non-bridge-scc,bridge-require-precise-merge. This would disable some optimizations in tarjan bridge, the perf impact should be lower than just using the new bridge.
• MONO_GC_DEBUG=check-remset-consistency,nursery-canaries. This does some internal heavy validation per GC collection. It would also attempt to detect some of the buffer overflows. Only to be used locally to attempt to reproduce crashes by finding incorrect state. Might make it easier to reproduce as well in order to be able to investigate.
• using CoreCLR runtime (only on .net10), which is currently experimental, but we will focus more on it for following releases. Add <UseMonoRuntime>false</UseMonoRuntime> to the csproj. This might provide better perf compared to mono.