dumpalc makes dotnet dump analyze exit #3565
Description
Description
I am trying to debug a simple dump from an .NET 7 application's dump generated through dotnet new web.
Running dumpalc against an address from clrstack -a makes dotnet-dump exit without any additional details.
[root@2a36e1cdbd5d test]# dotnet dump analyze TestDir/coredump.1071
Loading core dump: TestDir/coredump.1071 ...
Ready to process analysis commands. Type 'help' to list available commands or 'help [command]' to get detailed help on a command.
Type 'quit' or 'exit' to exit the session.
> sosstatus
Target OS: LINUX Architecture: X64 ProcessId: 1071 (0x42F)
Dump path: /test/TestDir/coredump.1071
#0 .NET Core runtime at 00007F1D8BBF9000 size 006CE000 index 01caa273a8525821d304dbc99b858bbc27442a57
Runtime module path: /usr/lib64/dotnet/shared/Microsoft.NETCore.App/7.0.0/libcoreclr.so
Current symbol store settings:
-> Directory: /test/TestDir
-> Cache: /root/.dotnet/symbolcache
-> Server: https://msdl.microsoft.com/download/symbols/ Timeout: 4 RetryCount: 3
GC memory usage for managed SOS components: 1,592,976 bytes
> clrstack -a
OS Thread Id: 0x42f (0)
Child SP IP Call Site
00007FFCE1C73780 00007f1d8c45f39a [HelperMethodFrame_1OBJ: 00007ffce1c73780] System.Threading.Monitor.ObjWait(Int32, System.Object)
00007FFCE1C738B0 00007F1D0CF14606 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken)
PARAMETERS:
this (0x00007FFCE1C738C0) = 0x00007edd120d55e8
millisecondsTimeout (<CLR reg>) = 0x00000000ffffffff
cancellationToken = <no data>
LOCALS:
<CLR reg> = 0x0000000000000000
<CLR reg> = 0x0000000000000000
<CLR reg> = 0x00000000ffffffff
<no data>
<no data>
<no data>
0x00007FFCE1C738B8 = 0x00007edd120d56f8
<no data>
0x00007FFCE1C738CC = 0x0000000000000000
<no data>
00007FFCE1C73930 00007F1D0CF28FCC System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken)
PARAMETERS:
this (0x00007FFCE1C73948) = 0x00007edd120d5510
millisecondsTimeout = <no data>
cancellationToken = <no data>
LOCALS:
<no data>
<no data>
<no data>
0x00007FFCE1C73940 = 0x00007edd120d55e8
0x00007FFCE1C73954 = 0x0000000000000000
<no data>
<no data>
00007FFCE1C73990 00007F1D0CF28E5E System.Threading.Tasks.Task.InternalWaitCore(Int32, System.Threading.CancellationToken)
PARAMETERS:
this (<CLR reg>) = 0x00007edd120d5510
millisecondsTimeout = <no data>
cancellationToken = <no data>
LOCALS:
<no data>
<CLR reg> = 0x00007edd14401448
<CLR reg> = 0x0000000000000000
<no data>
<no data>
00007FFCE1C739E0 00007F1D0CF766A4 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
PARAMETERS:
task (<CLR reg>) = 0x00007edd120d5510
LOCALS:
<no data>
<no data>
00007FFCE1C73A00 00007F1D0DA224D5 Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(Microsoft.Extensions.Hosting.IHost)
PARAMETERS:
host = <no data>
LOCALS:
<no data>
<no data>
00007FFCE1C73A20 00007F1D0D8A0BF3 Program.<Main>$(System.String[]) [/test/TestDir/Program.cs @ 6]
PARAMETERS:
args (0x00007FFCE1C73A78) = 0x00007edd1200ee70
LOCALS:
0x00007FFCE1C73A70 = 0x00007edd12010008
0x00007FFCE1C73A68 = 0x00007edd1203d6d8
> dumpalc 0x00007edd120d55e8
139ot@2a36e1cdbd5d test]#
The terminal state is corrupted after dotnet dump exits (requires a reset). That 139 is the output from echo $? which I ran right after the program exited.
The SDK/Runtime are source-built. But I checked against a Microsoft-build of .NET 7.0.101 and that seemed to have the same issue.
Here's my complete test script: https://gist.github.com/omajid/414ed2bbcf54ae5d259960898533541c. It works against .NET 6 but fails against .NET 7.
Configuration
- Is this related to a specific tool? Yes,
dotnet dump analyze -c dumpalc - What OS and version, and what distro if applicable? CentOS Stream 9, using the container
quay.io/centos/centos:stream9-development - What is the architecture (x64, x86, ARM, ARM64)?
x64(called x86_64 by CentOS Stream) - Do you know whether it is specific to that configuration? No idea.
- Are you running in any particular type of environment? (e.g. Containers, a cloud scenario, app you are trying to target is a different user) I am running in a container. But the same
- Is it a self-contained published application? No
- What's the output of
dotnet info
.NET SDK:
Version: 7.0.100
Commit: e12b7af219
Runtime Environment:
OS Name: centos
OS Version: 9
OS Platform: Linux
RID: centos.9-x64
Base Path: /usr/lib64/dotnet/sdk/7.0.100/
Host:
Version: 7.0.0
Architecture: x64
Commit: d099f075e4
.NET SDKs installed:
7.0.100 [/usr/lib64/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 7.0.0 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 7.0.0 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
Regression?
The same version of dotnet dump "works" against .NET 6, printing out an error and continuing on.
> dumpalc 0x00007fc9f000dfc0
Name: System.Runtime.Loader.DefaultAssemblyLoadContext
The managed instance of this context doesn't exist yet