Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(3)

Side by Side Diff: docs/linux_minidump_to_core.md

Issue 1309473002: WIP: Migrate Wiki content over to src/docs (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: Created 5 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « docs/linux_hw_video_decode.md ('k') | docs/linux_open_suse_build_instructions.md » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(Empty)
1 # Introduction
2
3 On Linux, Chromium can use Breakpad to generate minidump files for crashes. It i s possible to convert the minidump files to core files, and examine the core fil e in gdb, cgdb, or Qtcreator. In the examples below cgdb is assumed but any gdb based debugger can be used.
4
5 # Details
6
7 ## Creating the core file
8
9 Use `minidump-2-core` to convert the minidump file to a core file. On Linux, one can build the minidump-2-core target in a Chromium checkout, or alternatively, build it in a Google Breakpad checkout.
10
11 ```
12
13 $ minidump-2-core foo.dmp > foo.core
14
15 ```
16
17 ## Retrieving Chrome binaries
18
19 If the minidump is from
20 a public build then Googlers can find Google Chrome Linux binaries and debugging symbols via https://goto.google.com/chromesymbols. Otherwise, use the locally b uilt chrome files.
21 Google Chrome uses the _debug link_ method to specify the debugging file.
22 Either way be sure to put chrome and chrome.debug
23 (the stripped debug information) in the same directory as the core file so that the debuggers can find them.
24
25 ## Loading the core file into gdb/cgdb
26
27 The recommended syntax for loading a core file into gdb/cgdb is as follows, spec ifying both the executable and the core file:
28
29 ```
30
31 $ cgdb chrome foo.core
32
33 ```
34
35 If the executable is not available then the core file can be loaded on its own b ut debugging options will be limited:
36
37 ```
38
39 $ cgdb -c foo.core
40
41 ```
42
43 ## Loading the core file into Qtcreator
44
45 Qtcreator is a full GUI wrapper for gdb and it can also load Chrome's core files . From Qtcreator select the Debug menu, Start Debugging, Load Core File... and t hen enter the paths to the core file and executable. Qtcreator has windows to di splay the call stack, locals, registers, etc. For more information on debugging with Qtcreator see [Getting Started Debugging on Linux.](https://www.youtube.com /watch?v=xTmAknUbpB0)
46
47 ## Source debugging
48
49 If you have a Chromium repo that is synchronized to exactly (or even approximate ly) when the Chrome build was created then you can tell gdb/cgdb/Qtcreator to lo ad source code. Since all source paths in Chrome are relative to the out/Release directory you just need to add that directory to your debugger search path, by adding a line similar to this to ~/.gdbinit:
50
51 ```
52
53 (gdb) directory /usr/local/chromium/src/out/Release/
54
55 ```
56
57 ## Notes
58
59 * Since the core file is created from a minidump, it is incomplete and the deb ugger may not know values for variables in memory. Minidump files contain thread stacks so local variables and function parameters should be available, subject to the limitations of optimized builds.
60 * For gdb's `add-symbol-file` command to work, the file must have debugging sy mbols.
61 * In case of separate debug files, [the gdb manual](https://sourceware.org/g db/onlinedocs/gdb/Separate-Debug-Files.html) explains how gdb looks for them.
62 * If the stack trace involve system libraries, the Advanced module loading ste ps shown below need to be repeated for each library.
63
64 ## Advanced module loading
65
66 If gdb doesn't find shared objects that are needed you can force it to load them . In gdb, the `add-symbol-file` command takes a filename and an address. To figu re out the address, look near the end of `foo.dmp`, which contains a copy of `/p roc/pid/maps` from the process that crashed.
67
68 One quick way to do this is with `grep`. For instance, if the executable is `/pa th/to/chrome`, one can simply run:
69
70 ```
71
72 $ grep -a /path/to/chrome$ foo.dmp
73
74 7fe749a90000-7fe74d28f000 r-xp 00000000 08:07 289158 /path/t o/chrome
75 7fe74d290000-7fe74d4b7000 r--p 037ff000 08:07 289158 /path/t o/chrome
76 7fe74d4b7000-7fe74d4e0000 rw-p 03a26000 08:07 289158 /path/t o/chrome
77
78
79 ```
80
81 In this case, `7fe749a90000` is the base address for `/path/to/chrome`, but gdb takes the start address of the file's text section. To calculate this, one will need a copy of `/path/to/chrome`, and run:
82
83 ```
84
85 $ objdump -x /path/to/chrome | grep '\.text' | head -n 1 | tr -s ' ' | cut -d' ' -f 7
86
87 005282c0
88
89 ```
90
91 Now add the two addresses: `7fe749a90000 + 005282c0 = 7fe749fb82c0` and in gdb, run:
92
93 ```
94
95 (gdb) add-symbol-file /path/to/chrome 0x7fe749fb82c0
96
97 ```
98
99 Then use gdb as normal.
100
101 ## Other resources
102
103 For more discussion on this process see [Debugging a Minidump](http://www.chromi um.org/chromium-os/how-tos-and-troubleshooting/crash-reporting/debugging-a-minid ump). This page discusses the same process in the context of ChromeOS and many o f the concepts and techniques overlap.
OLDNEW
« no previous file with comments | « docs/linux_hw_video_decode.md ('k') | docs/linux_open_suse_build_instructions.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698