diagnostics: dotnet-dump on Debian 9 fails with Core dump generation FAILED

So I’m getting two errors in the context of running dotnet-dump on Debian 9. This is a VM and not a docker container.

The first is a permission error.

$ /opt/dotnet/tools/dotnet-dump collect -p 19668
Writing minidump with heap to /home/userfolder1/core_20190826_201258
Unhandled exception: System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (13): Permission denied /tmp/dotnet-diagnostic-19668-22628141-socket
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   at Microsoft.Diagnostics.Tools.RuntimeClient.DiagnosticsIpc.IpcClient.GetTransport(Int32 processId) in /_/src/Microsoft.Diagnostics.Tools.RuntimeClient/DiagnosticsIpc/IpcClient.cs:line 55
   at Microsoft.Diagnostics.Tools.RuntimeClient.DiagnosticsIpc.IpcClient.SendMessage(Int32 processId, IpcMessage message) in /_/src/Microsoft.Diagnostics.Tools.RuntimeClient/DiagnosticsIpc/IpcClient.cs:line 67
   at Microsoft.Diagnostics.Tools.RuntimeClient.DiagnosticsHelpers.GenerateCoreDump(Int32 processId, String dumpName, DumpType dumpType, Boolean diagnostics) in /_/src/Microsoft.Diagnostics.Tools.RuntimeClient/DiagnosticsHelpers.cs:line 46
   at Microsoft.Diagnostics.Tools.Dump.Dumper.Collect(IConsole console, Int32 processId, String output, DumpTypeOption type) in /_/src/Tools/dotnet-dump/Dumper.cs:line 67
   at System.CommandLine.Invocation.CommandHandler.GetResultCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass2_0.<<InvokeAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseParseErrorReporting>b__16_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c__DisplayClass8_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseSuggestDirective>b__7_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseParseDirective>b__6_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseHelp>b__14_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass3_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c.<<RegisterWithDotnetSuggest>b__17_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Invocation.InvocationExtensions.<>c__DisplayClass5_0.<<UseExceptionHandler>b__0>d.MoveNext()

To which the answer is to always sudo right? :trollface: but after I run that I get “Core dump generation FAILED”

$ sudo /opt/dotnet/tools/dotnet-dump collect -p 19668
Writing minidump with heap to /home/userfolder1/core_20190826_201301
Core dump generation FAILED 0x80004005

General info:

$/opt/dotnet/tools/dotnet-dump --version
3.0.0-preview8.19412.1+a7f67ec8e78640b0d73e123c5ee66811afb8be35

$dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview8-013656
 Commit:    8bf06ffc8d

Runtime Environment:
 OS Name:     debian
 OS Version:  9
 OS Platform: Linux
 RID:         debian.9-x64
 Base Path:   /usr/share/dotnet/sdk/3.0.100-preview8-013656/

Host (useful for support):
  Version: 3.0.0-preview8-28405-07
  Commit:  d01b2fb7bc

.NET Core SDKs installed:
  3.0.100-preview8-013656 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0-preview8.19405.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0-preview8-28405-07 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 21 (10 by maintainers)

Commits related to this issue

Add architecture option dotnet-sos Issue: https://github.com/dotnet/diagnostics/issues/406 Add --diag option to dotnet-dump collect to help diagnose issues like https://github.com/dotnet/diagnostics... — committed to mikem8361/diagnostics by mikem8361 5 years ago
Add architecture option dotnet-sos (#450) Add architecture option dotnet-sos Issue: https://github.com/dotnet/diagnostics/issues/406 Add --diag option to dotnet-dump collect to help diagnose is... — committed to dotnet/diagnostics by mikem8361 5 years ago

Most upvoted comments

I created this issue about better error messaging: https://github.com/dotnet/diagnostics/issues/733.

Changing the to use the temp directory is too much of a breaking change.

mikem8361 on Jan 8, 2020

Moving to 5.0 to track this portion of the issue:

Possibly give a better error than Core dump generation FAILED 0x80004005? I’m unsure if the channel dotnet-dump talks through is able to gather that?

Possibly default to the users temp folder instead of current? Probably a breaking change.

This part is done:

Add the FAQ what to do when you get the Permission denied /tmp/dotnet-diagnostic-19668-22628141-socket error

tommcdon on Sep 13, 2019

@TheAngryByrd thanks for all the feedback 😃 it’s hard to imagine all the different setups people may have and it’s hard to document these scenarios if we don’t hear of their existence in the wild. Hope your scenario got unblocked, and lets us know if you need any help with other bugs or behaviors you think should be documented.

hoyosjs on Aug 27, 2019

I’m adding a --diag option to dotnet-dump collect so the dump creation logging is displayed. Unfortunately it is on the target process console like the above Permission denied message, but there really isn’t a lot we can do for 3.x since this all happens on the runtime side. The dotnet-dump side really only gets a pass/fail indication even though it looks like an HRESULT (always E_FAIL).

mikem8361 on Aug 26, 2019

I would definitely like to make this better but there is only a HRESULT for status back from the runtime when the createdump fails.
You can use the dotnet-dump collect --output option to specific the file/path. Changing the default may be a breaking change like you said.
I’ll add that to the FAQ.

mikem8361 on Aug 26, 2019

Ok I can confirm dumping the service as the same user works but fails with Permission denied /tmp/dotnet-diagnostic-19668-22628141-socket when trying to dump a process from another user.

TheAngryByrd on Aug 26, 2019

You shouldn’t need sudo/superuser unless the app was launched as root or another user (and maybe not even then).

Including the rest of the diagnostic team @dotnet/dotnet-diag to see if there is anything obvious.

mikem8361 on Aug 26, 2019