GC Collection Crash

[lilleydnSub]

Apple platform

macOS

Framework version

net10.0-*

Affected platform version

.Net version 10.0.101 Apple Xcode 26.3

Description

We have been hit with a problem with GC collection and have been unable to find what is causing the issue. Unsure if this dotnet issue but we seem to hit this few times and unable to much about it.

See file attached for macOS crash

Steps to Reproduce

Unable to reproduce on demand but it happens.

Did you find any workaround?

No response

Relevant logs

crash report.txt

[rolfbjarne]

Unfortunately there's not much to go on here:

Crashed Thread:        18  .NET BGC

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x040043bba8c17bf8 -> 0x000043bba8c17bf8 (possible pointer authentication failure)
Exception Codes:       0x0000000000000001, 0x040043bba8c17bf8

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [1312]

VM Region Info: 0x43bba8c17bf8 is not in any region.  Bytes after previous region: 73992232860665  Bytes before following region: 31079847068680
     REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
     commpage (reserved)        1000000000-7000000000   [384.0G] ---/--- SM=NUL  reserved VM address space (unallocated)
--->  GAP OF 0x5f9000000000 BYTES
     MALLOC_NANO              600000000000-600020000000 [512.0M] rw-/rwx SM=PRV  
[...]
Thread 18 Crashed:: .NET BGC
0   libobjc.A.dylib               	       0x193e7deb0 lookUpImpOrForward + 72
1   libobjc.A.dylib               	       0x193e7db84 _objc_msgSend_uncached + 68
2   BankingZV                     	       0x1008a9cf0 xamarin_gc_toggleref_callback + 64
3   BankingZV                     	       0x1008b25c8 xamarin_coreclr_reference_tracking_is_referenced_callback + 44
4   libcoreclr.dylib              	       0x1011f7d24 ObjCMarshalNative::IsTrackedReference(Object*, bool*) + 96
5   libcoreclr.dylib              	       0x101167ba8 GCToEEInterface::RefCountedHandleCallbacks(Object*) + 76
6   libcoreclr.dylib              	       0x10120c1dc PromoteRefCounted(Object**, unsigned long*, unsigned long, unsigned long) + 80
7   libcoreclr.dylib              	       0x10120a314 BlockScanBlocksWithoutUserData(TableSegment*, unsigned int, unsigned int, ScanCallbackInfo*) + 116
8   libcoreclr.dylib              	       0x10120bc34 TableScanHandles(HandleTable*, unsigned int const*, unsigned int, TableSegment* (*)(HandleTable*, TableSegment*, Holder<CrstBase*, &CrstBase::AcquireLock(CrstBase*), &CrstBase::ReleaseLock(CrstBase*), 0ul, &int CompareDefault<CrstBase*>(CrstBase*, CrstBase*), true>*), void (*)(TableSegment*, unsigned int, unsigned int, ScanCallbackInfo*), ScanCallbackInfo*, Holder<CrstBase*, &CrstBase::AcquireLock(CrstBase*), &CrstBase::ReleaseLock(CrstBase*), 0ul, &int CompareDefault<CrstBase*>(CrstBase*, CrstBase*), true>*) + 392
9   libcoreclr.dylib              	       0x101206e1c HndScanHandlesForGC(HandleTable*, void (*)(Object**, unsigned long*, unsigned long, unsigned long), unsigned long, unsigned long, unsigned int const*, unsigned int, unsigned int, unsigned int, unsigned int) + 356
10  libcoreclr.dylib              	       0x10120d83c Ref_TraceNormalRoots(unsigned int, unsigned int, ScanContext*, void (*)(Object**, ScanContext*, unsigned int)) + 560
11  libcoreclr.dylib              	       0x1012706a8 WKS::gc_heap::background_mark_phase() + 1592

[rolfbjarne]

That said, I have a few questions to get started:

• Approximately how frequent is this? Something you see during development once in a while, or only customers run into it once in a while?
• Is there anything in particular the app is doing when it crashes (or just did, since it's a GC crash it can be something that happened a little bit in the past)?
• Any patterns (specific type of macOS hardware, only on some macOS versions, etc.)? Having as many crash reports as possible can be valuable (even if they look identical) to establish if there is a pattern somewhere.

[dotnet-policy-service]

Hi @lilleydnSub. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.