Test failure: System.Security.Cryptography.Tests

[JulieLeeMSFT]

Build Information

Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1500206
Build error leg or test failing: System.Security.Cryptography.Tests

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "exit code 139 means SIGSEGV Illegal memory access",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1500206
Error message validated: [Condition(s) not met: "SupportsSha3"]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 7/9/2026 10:47:37 PM UTC

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1500206
Error message validated: [exit code 139 means SIGSEGV Illegal memory access]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 7/9/2026 10:52:19 PM UTC

Report

Build	Repository	Test	Pull Request
1502372	dotnet/runtime	System.Runtime.Intrinsics.Tests.WorkItemExecution	#130444
1500206	dotnet/runtime	System.Security.Cryptography.Tests.WorkItemExecution

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
1	2	2

[dotnet-policy-service]

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

[vcsjones]

This is a segfault, it is unlike related to the SHA-3 output, that's just the console log indicating the platform does not support SHA-3. I updated the error message and will see if I can figure out the source of the fault.

[vcsjones]

This is the native stack

Crashing native thread: 0x49eb
Signal: SIGSEGV (11)

#00 0x1077456a4 MethodTable::Validate()
#01 0x107749d98 Object::ValidateInner(int, int, int)
#02 0x10796482c TGcInfoDecoder<InterpreterGcInfoEncoding>::ReportStackSlotToGC(...)
#03 0x107962378 TGcInfoDecoder<InterpreterGcInfoEncoding>::EnumerateLiveSlots(...)
#04 0x10769ae8c InterpreterCodeManager::EnumGcRefs(...)
#05 0x10786d5dc GcStackCrawlCallBack(CrawlFrame*, void*)
#06 0x10778273c Thread::MakeStackwalkerCallback(...)
#07 0x107782918 Thread::StackWalkFramesEx(...)
#08 0x10778394c Thread::StackWalkFrames(...)
#09 0x1078692cc ScanStackRoots(Thread*, ...)
#10 0x107868e5c GCToEEInterface::GcScanRoots(...)
#11 0x1075aa8f0 WKS::gc_heap::background_mark_phase()
#12 0x1075907f0 WKS::gc_heap::gc1()
#13 0x1075a9bf4 WKS::gc_heap::bgc_thread_function()
#14 0x10786c7cc CreateSuspendableThread(...)::__invoke(void*)
#15 0x1079e36e0 CorUnix::CPalThread::ThreadEntry(void*)
#16 0x19ad1bc08 _pthread_start

Copilot believes this to be an issue with the interpreter GC

During background GC, the runtime enumerated the first argument slot of:

Xunit.Sdk.TestInvoker<TTestCase>.CallTestMethod(object)

as a direct managed object reference. The slot instead contained the address of another interpreter-stack slot. Debug GC validation followed this extra indirection as though it were an object and eventually passed a managed object address to  MethodTable::Validate , causing  SIGSEGV .

The dump conclusively identifies the invalid GC root and affected method. It narrows the implementation defect to the interpreter’s shared-generic this handling and argument/root lifetime. The precise operation that changed or represented the slot indirectly is not established from the dump alone.

The “invalid object” is an interpreter-stack address that points to a valid object reference, whose actual  MethodTable  is also valid. This structured, single-extra-indirection pattern—at the shared-generic  this  slot—is characteristic of incorrect GC metadata or argument representation, not random heap damage.

MethodTable::Validate  makes the failure resemble heap corruption, but it is validating the wrong address. There is no observed corruption of the actual managed object or its  MethodTable ; the evidence instead indicates an interpreter stack/root-reporting bug.

I don't see anything indicating that this is related to cryptography's code itself as the actual crash fairly far away from it.

[dotnet-policy-service]

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