diff options
author | Amar Tumballi <amarts@redhat.com> | 2018-07-20 11:04:01 +0530 |
---|---|---|
committer | Shyamsundar Ranganathan <srangana@redhat.com> | 2018-08-01 18:41:21 +0000 |
commit | e91bffad97da117f2c4eb8db45ab7874e59addf5 (patch) | |
tree | 4a1b7132b59da7dba43598f3280ea390efffad28 /doc | |
parent | f354af3a56604c61e09e29c13fe8fb632c1013a8 (diff) |
doc: keep just one copy of a coredump analysis
Keeping two copies of the files means, one would be out-of-date soon,
and users would always be confused about which one is the source of
truth.
Updates: bz#1193929
Change-Id: I568149732fdb9d282ccd583640eee9b9056963fd
Signed-off-by: Amar Tumballi <amarts@redhat.com>
Diffstat (limited to 'doc')
-rw-r--r-- | doc/debugging/analyzing-regression-cores.md (renamed from doc/developer-guide/coredump-analysis.md) | 10 | ||||
-rw-r--r-- | doc/debugging/coredump-analysis.md | 31 |
2 files changed, 5 insertions, 36 deletions
diff --git a/doc/developer-guide/coredump-analysis.md b/doc/debugging/analyzing-regression-cores.md index 16fa9165fd0..cbbb387794d 100644 --- a/doc/developer-guide/coredump-analysis.md +++ b/doc/debugging/analyzing-regression-cores.md @@ -3,20 +3,20 @@ machines, with examples. 1) Download the core-tarball and extract it. 2) 'cd' into directory where the tarball is extracted. ~~~ -[root@atalur Downloads]# pwd -/home/atalur/Downloads -[root@atalur Downloads]# ls +[sh]# pwd +/home/user/Downloads +[sh]# ls build build-install-20150625_05_42_39.tar.bz2 lib64 usr ~~~ 3) Determine the core file you need to examine. There can be more than one core file. You can list them from './build/install/cores' directory. ~~~ -[root@atalur Downloads]# ls build/install/cores/ +[sh]# ls build/install/cores/ core.9341 liblist.txt liblist.txt.tmp ~~~ In case you are unsure which binary generated the core-file, executing 'file' command on it will help. ~~~ -[root@atalur Downloads]# file ./build/install/cores/core.9341 +[sh]# file ./build/install/cores/core.9341 ./build/install/cores/core.9341: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/build/install/sbin/glusterfsd -s slave26.cloud.gluster.org --volfile-id patchy' ~~~ As seen, the core file was generated by glusterfsd binary, and path to it is provided (/build/install/sbin/glusterfsd). diff --git a/doc/debugging/coredump-analysis.md b/doc/debugging/coredump-analysis.md deleted file mode 100644 index f9ecf73216e..00000000000 --- a/doc/debugging/coredump-analysis.md +++ /dev/null @@ -1,31 +0,0 @@ -This document explains how to analyze core-dumps obtained from regression -machines, with examples. -1) Download the core-tarball and extract it. -2) 'cd' into the root of extracted tarball. -~~~ -[root@atalur Downloads]# pwd -/home/atalur/Downloads -[root@atalur Downloads]# ls -build build-install-20150625_05_42_39.tar.bz2 lib64 usr -~~~ -3) Determine the core file you need to examine. There can be more than one core file. -You can list them from './build/install/cores' directory. -~~~ -[root@atalur Downloads]# ls build/install/cores/ -core.9341 liblist.txt liblist.txt.tmp -~~~ -In case you are unsure which binary generated the core-file, executing 'file' command on it will help. -~~~ -[root@atalur Downloads]# file ./build/install/cores/core.9341 -./build/install/cores/core.9341: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/build/install/sbin/glusterfsd -s slave26.cloud.gluster.org --volfile-id patchy' -~~~ -As seen, the core file was generated by glusterfsd binary, and path to it is provide (/build/install/sbin/glusterfsd). -4) Now, run the following command on the core: -~~~ -gdb -ex 'set sysroot ./' -ex 'core-file ./build/install/cores/core.xxx' <target, say ./build/install/sbin/glusterd> -In this case, -gdb -ex 'set sysroot ./' -ex 'core-file ./build/install/cores/core.9341' ./build/install/sbin/glusterfsd -~~~ -5) You can cross check if all shared libraries are available and loaded by using 'info sharedlibrary' command from -inside gdb. -6) Once verified, usual gdb commands based on requirement can be used to debug the core. |