Test failure: System.Threading.Threads.Tests.ThreadTests.DefaultPrincipalPolicyTest

[VincentBu]

Failed in: runtime-coreclr libraries-jitstress 20260330.1

Failed tests:

net11.0-linux-Release-arm64-jitminopts-AzureLinux.3.Arm64.Open
- System.Threading.Threads.Tests.ThreadTests.DefaultPrincipalPolicyTest

Error message:

Microsoft.DotNet.RemoteExecutor.RemoteExecutionException : Exit code was 139 but it should have been 42

Stack trace:

   at Microsoft.DotNet.RemoteExecutor.RemoteInvokeHandle.Dispose(Boolean disposing) in /_/src/arcade/src/Microsoft.DotNet.RemoteExecutor/src/RemoteInvokeHandle.cs:line 242
   at Microsoft.DotNet.RemoteExecutor.RemoteInvokeHandle.Dispose() in /_/src/arcade/src/Microsoft.DotNet.RemoteExecutor/src/RemoteInvokeHandle.cs:line 55
   at System.Threading.Threads.Tests.ThreadTests.DefaultPrincipalPolicyTest() in /_/src/libraries/System.Threading.Thread/tests/ThreadTests.cs:line 1300
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args) in /_/src/coreclr/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.CoreCLR.cs:line 39
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr) in /_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs:line 57

[dotnet-policy-service]

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

[jkotas]

Log:

  Starting:    System.Threading.Thread.Tests (parallel test collections = on [2 threads], stop on fail = off)
[createdump] Gathering state for process 4779 dotnet
[createdump] Crashing thread 12ab signal 11 (000b)
ASSERT FAILED
	Expression: pRD->_pThread->IsExecutingOnAltStack() || PTR_VOID(pRD->SP) >= pRD->_pThread->GetCachedStackLimit()
	Location:   /__w/1/s/src/coreclr/vm/threads.cpp:5684
	Function:   CheckRegDisplaySP
	Process:    4788
waitpid() returned successfully (wstatus 00000085) WEXITSTATUS 0 WTERMSIG 5
    System.Threading.Threads.Tests.ThreadTests.DefaultPrincipalPolicyTest [FAIL]

[dotnet-policy-service]

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

[mangod9]

Here is a diag analysis:

Complete Diagnosis of #126339

Two distinct crashes found in the Helix dumps:

Crash 1: PID 4779 (dotnet) — SIGSEGV (signal 11)

 DbgTransportSession::AbortConnection     ← ldr x8, [x0=NULL] → SIGSEGV
   TerminateCurrentProcessNoExit
     ExitProcess → PROCEndProcess
       SafeExitProcess
         Environment.Exit(42)              ← managed, MinOptJitted
           RemoteExecutor.Program.Main

Root cause: During Environment.Exit(42), the shutdown path calls DbgTransportSession::AbortConnection() which
dereferences m_channel->CloseConnection() without a NULL check. The m_channel field is NULL because no debugger
ever connected. The right-side counterpart CleanupTargetProcess() at line 241 has a if (m_channel == NULL)
return; guard — AbortConnection() is missing it.

Fix: Add if (m_channel != NULL) guard in AbortConnection().

Crash 2: PID 4788 (createdump) — CheckRegDisplaySP assert

 DBG_DebugBreak
   DebugBreak
     CheckRegDisplaySP(pRD)                ← ASSERT: SP >= CachedStackLimit
       Thread::FillRegDisplay
         ClrDataStackWalk::Init
           ClrDataTask::CreateStackWalk
             ThreadInfo::UnwindThread      ← createdump walking crashed process

Root cause: When createdump tries to walk thread 0x12ab's stack in the crashed process (4779), the CONTEXT it
reads via ptrace has a garbage SP value of 0xFB9D48C70AE0 — this actually points into System.Threading.Thread.dll
's metadata section, not the stack at all (stack is near 0xFFFF_C1DEF000). The CheckRegDisplaySP debug assert
correctly catches this invalid SP.

Why the SP is garbage: The process was in the middle of TerminateCurrentProcessNoExit → AbortConnection when it
got SIGSEGV. The signal handler captured the CONTEXT at the crash point. Since the crash was during PAL cleanup
(native shutdown code), the saved context may have had SP pointing to a scratch/trampled value during the signal
delivery on ARM64. This is a secondary issue — the assert fires during dump creation of an already-crashing
process.

Key Finding

The primary bug is the missing NULL check in DbgTransportSession::AbortConnection(). The CheckRegDisplaySP assert
is a consequence — it only fires because createdump is trying to dump a process that crashed due to this bug. The
assert itself is a debug-only diagnostic that's working as intended (detecting that the crash context has invalid
state).

The race is between two shutdown paths:

Path A (normal): Environment.Exit → EEShutDown → Debugger::StopDebugger:

 // debugger.cpp:879
 if (g_pDbgTransport != NULL)
 {
     g_pDbgTransport->Shutdown();
     g_pDbgTransport = NULL;  // ← cleared BEFORE PAL exit runs
 }

Path B (PAL exit): ExitProcess → PROCNotifyProcessShutdown → CleanupTransportSocket:

 // debugger.cpp:1701
 if (g_pDbgTransport != NULL)  // ← if StopDebugger already ran, this is NULL → safe
 {
     g_pDbgTransport->AbortConnection();  // ← crash
 }

Most of the time: Path A runs first during normal EEShutDown, clears g_pDbgTransport = NULL, then Path B fires
and skips the call. No crash.

Under jitminopts: The MinOpt-jitted shutdown code is more fragile — if EEShutDown fails or takes an exception
partway through (note the PAL_SEHException::FreeRecords in the crash stack), StopDebugger never runs, 
g_pDbgTransport remains non-NULL, and Path B dereferences the NULL m_channel.

So the intermittency is: does EEShutDown complete successfully before the PAL exit path fires? Under normal JIT,
yes. Under jitminopts, occasionally not.