dotnet-symbol ReadMe clarification
Sean-Driscoll opened this issue · comments
The dotnet-symbol readme mentions the following:
The best way to generate core dumps on Linux (not supported on Windows or OSX) is to use the createdump facility that is part of .NET Core 2.0 and greater. It can be setup to automatically generate a "minidump" like ELF core dump when your .NET Core app crashes. The normal Linux system core generation also works just fine but they are usually a lot larger than necessary.
My questions:
- How do you setup createdump to automatically generate core dump if .NET Core app crashes?
- The "normal Linux system core generation also works just fine" comment is contrary to the comment here that states "Dumps created with gdb or gcore do not have all the managed state". Which is correct?
Also, I'm trying to understand how to use portable pdbs on Linux, or at all for that matter, and my search led to this dotnet-symbol tool. Do I need to use dotnet-symbol at all? Assuming I have portable PDBs and a core dump from a .NET Core 3.1 app, what tools can actually use portable PDBs besides VS?
-
There is a link to the createdump configuration doc in the dotnet-symbol readme that should help: https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy
-
Without setting the /proc/<pid>/coredump_filter flags to at least 0x3f (see below) all three ways (Linux system core dump, gdb or gcore) will not contain all the managed state needed in these dumps.
echo 0x3f > /proc/self/coredump_filter
ulimit -c unlimited
If the .NET Core app is launched from this shell and crashes, the resulting core dumps should have all the managed state but they are going to be bigger than the createdump generated dumps. There also seems to be issues (#47) with some gdb and gcore generated core dumps (I should have put more technical details in the issue) with the dotnet-symbol and the SOS downloading.
As far as what tools use portable PDBs it is like you said VS, VSCode and SOS for debugging. I'm not sure all the tools that support them at this time.
If you want to use SOS to debug core dumps (via lldb or dotnet-dump), you only need dotnet-symbol to get the "host" program (dotnet or the self-contained app host which is apphost renamed to your project name) using the --host-only option. SOS itself will download the portable PDB's for the runtime assemblies in the stack (via clrstack or pe).
Thanks @mikem8361. Comment and couple follow-ups.
The documentation you referenced for createdump is helpful. I had seen it before but hadn't understood it was for setting up automatic core dumps using createdump. Also, the first line in that section mentions docker containers so I naively assumed I wouldn't need it at all. That said, perhaps the start of the section can be a little more explicit regarding what the configuration/policy is for, or why you need them.
My followup questions
- Regarding your answer to question 2 above, does the core dump created by the createdump utility contain all the necessary manage state regardless of the coredump_filter flag?
- You mentioned SOS uses portable PDBs, are you talking both sos and the lldb sos extension? I couldn't get the portable PDB to work with sos from Windbg Preview.
Yes, createdump generated core dumps contain all the managed state needed regardless of the coredump_filter flags.
Yes, SOS on Windows, Linux and MacOS all support portable PDBs. Even the SOS with the windbg preview should work. What does your !setsymbolserver display?
Maybe a dumb question but do the environment variables for automatic core dump generation need to be set before the application starts?
Yes, the env vars need to be set in the shell that starts the app starts before the app is run.
@mikem8361 - thanks for answering all my questions! I think the documents mentioned here could use a little clarification but ultimately all the content is there (accept maybe the fact that coredump_filter set to 0x3F is not necessaryt when using createdump or dotdet-dump for that matter) so feel free to close this out.
PR #175