You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dotnet-dump analyze exposes synthetic OS thread IDs (0, 1, 2, …) when opening ELF core dumps produced by createdump on macOS arm64. SOS obtains the real OS thread IDs from the DAC, so the current thread never matches a managed thread and current-thread commands fail.
For example, clrstack reports:
OS Thread Id: 0x0 (0)
Unable to walk the managed stack. The current thread is likely not a managed thread.
Failed to start stack walk: 80070057
The same dump contains valid thread IDs. Apple's stock LLDB reports:
thread #1: tid = 0x6365e4
thread #2: tid = 0x6365f5
...
SOS clrthreads also reports the real IDs, including the crashing managed thread:
DBG ID OSID
XXXX 1 6365e4 ... System.DivideByZeroException
But dotnet-dump's threads command reports:
*0 0x0000 (0)
1 0x0001 (1)
...
Trying each setthread index does not help because SOS still receives the synthetic ID and cannot associate it with a DAC thread.
Configuration
Tool: dotnet-dump analyze
Dump producer: createdump
OS: macOS arm64
Dump format: ELF core
Observed with .NET 11 Heap dumps in the new SOS.Tests matrix
Reproduces with both the legacy DAC and cDAC and with Core and SingleFile targets
Unknown. The broader SOS harness exposed this when macOS arm64 dump coverage was added.
Other information
Current-thread-dependent commands affected include clrstack, clrstack -i, printexception, clrma, and stack-root operations. Dump-independent and LLDB-hosted tests continue to work.
The likely boundary is the data reader used by dotnet-dump to enumerate ELF core threads: the contexts are present, but IThreadReader.EnumerateOSThreadIds() yields note indexes rather than the thread IDs stored in the macOS core. The preferred fix is to preserve the actual thread IDs and initialize the current context to the captured/crashing thread.
Description
dotnet-dump analyzeexposes synthetic OS thread IDs (0,1,2, …) when opening ELF core dumps produced bycreatedumpon macOS arm64. SOS obtains the real OS thread IDs from the DAC, so the current thread never matches a managed thread and current-thread commands fail.For example,
clrstackreports:The same dump contains valid thread IDs. Apple's stock LLDB reports:
SOS
clrthreadsalso reports the real IDs, including the crashing managed thread:But dotnet-dump's
threadscommand reports:Trying each
setthreadindex does not help because SOS still receives the synthetic ID and cannot associate it with a DAC thread.Configuration
dotnet-dump analyzecreatedumpSOS.TestsmatrixRegression?
Unknown. The broader SOS harness exposed this when macOS arm64 dump coverage was added.
Other information
Current-thread-dependent commands affected include
clrstack,clrstack -i,printexception,clrma, and stack-root operations. Dump-independent and LLDB-hosted tests continue to work.The likely boundary is the data reader used by dotnet-dump to enumerate ELF core threads: the contexts are present, but
IThreadReader.EnumerateOSThreadIds()yields note indexes rather than the thread IDs stored in the macOS core. The preferred fix is to preserve the actual thread IDs and initialize the current context to the captured/crashing thread.