summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorMike McLaughlin <mikem@microsoft.com>2018-08-14 18:22:23 -0700
committerGitHub <noreply@github.com>2018-08-14 18:22:23 -0700
commit21f94f2be12e16bb36187d40c2fa82af9ebfd469 (patch)
tree5ff04e61eea1da1706e9dbf819af96af2ba90d2a /Documentation
parent1e20a920fb2caffbee7fba96c295f3a8185700be (diff)
downloadcoreclr-21f94f2be12e16bb36187d40c2fa82af9ebfd469.tar.gz
coreclr-21f94f2be12e16bb36187d40c2fa82af9ebfd469.tar.bz2
coreclr-21f94f2be12e16bb36187d40c2fa82af9ebfd469.zip
Update debugging and createdump docs. (#19495)
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/botr/xplat-minidump-generation.md8
-rw-r--r--Documentation/building/debugging-instructions.md6
2 files changed, 9 insertions, 5 deletions
diff --git a/Documentation/botr/xplat-minidump-generation.md b/Documentation/botr/xplat-minidump-generation.md
index 47d6e5cb7c..9c56c4cf8d 100644
--- a/Documentation/botr/xplat-minidump-generation.md
+++ b/Documentation/botr/xplat-minidump-generation.md
@@ -34,7 +34,7 @@ As long as control can making it to the signal/abort handler and the fork/execve
**Stack overflow exception**
-Like the severe memory corruption case, if the signal handler (`SIGSEGV`) gets control it can detect most stack overflow cases and does trigger a core dump. There are still many cases where this doesn't happen and the OS just terminates the process.
+Like the severe memory corruption case, if the signal handler (`SIGSEGV`) gets control it can detect most stack overflow cases and does trigger a core dump. There are still many cases where this doesn't happen and the OS just terminates the process. There is a bug in the earlier versions (2.1.x or less) of the runtime where _createdump_ isn't invoked for any stack overflow.
### FreeBSD/OpenBSD/NetBSD ###
@@ -57,7 +57,11 @@ Environment variables supported:
(Please refer to MSDN for the meaning of the [minidump enum values](https://msdn.microsoft.com/en-us/library/windows/desktop/ms680519(v=vs.85).aspx) reported above)
-**Utility command line options**:
+**Command Line Usage**
+
+The createdump utility can also be run from the command line on arbitrary .NET Core processes. The type of dump can be controlled with the below command switches. The default is a "minidump" which contains the majority the memory and managed state needed. Unless you have ptrace (CAP_SYS_PTRACE) administrative privilege, you need to run with sudo or su. The same as if you were attaching with lldb or other native debugger.
+
+`sudo createdump <pid>`
createdump [options] pid
-f, --name - dump path and file name. The pid can be placed in the name with %d. The default is "/tmp/coredump.%d"
diff --git a/Documentation/building/debugging-instructions.md b/Documentation/building/debugging-instructions.md
index d9a0761d26..6f5074ad05 100644
--- a/Documentation/building/debugging-instructions.md
+++ b/Documentation/building/debugging-instructions.md
@@ -135,13 +135,13 @@ However the common commands have been aliased so that you don't need the SOS pre
It is also possible to debug .NET Core crash dumps using lldb and SOS. In order to do this, you need all of the following:
- The crash dump file. We have a service called "Dumpling" which collects, uploads, and archives crash dump files during all of our CI jobs and official builds.
-- On Linux, there is an utility called `createdump` (see [doc](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md "doc")) that can be setup to generate core dumps when a managed app throws an unhandled exception or faults.
+- On Linux, there is an utility called `createdump` (see [doc](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy)) that can be setup to generate core dumps when a managed app throws an unhandled exception or faults.
- To get matching runtime and symbol binaries for the core dump use the symbol downloader CLI extension:
- Install the [.NET Core 2.1 SDK](https://www.microsoft.com/net/download/).
- - Install the symbol downloader extension: `dotnet tool install -g dotnet-symbol`.
+ - Install the symbol downloader extension: `dotnet tool install -g dotnet-symbol`. Make sure you are not in any project directory with a NuGet.Config that doesn't include nuget.org as a source.
- Run `dotnet symbol coredump` to download the runtime binaries and symbols.
- Check out the coreclr and corefx repositories at the appropriate commit for the appropriate source.
- - For more details see: [dotnet-symbol](https://github.com/dotnet/symstore/blob/master/src/dotnet-symbol/README.md).
+ - For further information see: [dotnet-symbol](https://github.com/dotnet/symstore/blob/master/src/dotnet-symbol/README.md).
- lldb version 3.9. The SOS plugin (i.e. libsosplugin.so) provided is now built for lldb 3.9. In order to install lldb 3.9 just run the following commands:
```
~$ echo "deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.9 main" | sudo tee /etc/apt/sources.list.d/llvm.list