If you instead have a Windows Chrome minidump, just load the minidump into Visual Studio or windbg, set up the Chrome symbol server and Microsoft symbol server, and enable source indexing. Instructions can be found on the Debugging Chromium on Windows page.

Calculate address for symbols

First, setup the necessary files for the debugger. You need both the original executables and/or libraries whose symbols you wish to calculate, and you will need their corresponding debug information. Googlers: See Setup files for debugger for how to get these for official images.

Calculate the base address of the crashing executable's .text section.

Googlers: Alternatively, you can try my generate_gdb_command_file script to automatically generate a gdb command file for adding all the symbol files. For the "--top" command-line option, specify the path to where your image is mounted. Then, pass the path to the file to which you redirected minidump-2-core's stderr.

If backtrace in gdb did not help

Sometimes, the gdb backtrace command (Use gdb to show a backtrace) doesn't show a stack trace any better than that of minidump_stackwalk (Use minidump_stackwalk to show a stack trace). If you think there's more to it than what those two are showing you, try this method to naively dump all the known symbol addresses seen on the stack. You'll see some false positives, but you may just find the name of a function that seems like a plausible place to look.

First, start from the above step of using gdb to show a backtrace. We can reuse the gdb command file that was generated for it. Googlers: If you didn't use my generate_gdb_command_file script, you can manually create the gdb command file containing any "add-symbol-file" commands you ran.

Second, determine the base address of the stack. The easiest way is to just look at the stack address in the minidump. This command will set the $sp_addr variable to the stack address of the first thread in the minidump:

If you want to be smarter, you can run minidump_stackwalk on the minidump (using the appropriate Breakpad symbols) and skip past any stack frames you can assume are accurate. You would do this by looking for the stack pointer of the last consecutive call frame found by "call frame info". For example, for issue https://crbug.com/217636 the stack pointer value would be 0x7e8b3440 given the following top-most (i.e. higher address) frames:

7 Xorg!OsSigHandler [osinit.c : 146 + 0x11]

r4 = 0x76fc9f7c r5 = 0x7e8b3440 r6 = 0x76bfb094 r7 = 0x00000000

r8 = 0x00000000 r9 = 0x00000020 r10 = 0x00000004 fp = 0x00000008

sp = 0x7e8b3430 pc = 0x76f90949

Found by: call frame info

8 libc-2.15.so + 0x25e6e

r4 = 0x774ec898 r5 = 0x76e9aeb8 r6 = 0x76bfb094 r7 = 0x00000000

r8 = 0x00000000 r9 = 0x00000020 r10 = 0x00000004 fp = 0x00000008

sp = 0x7e8b3440 pc = 0x76b40e70

Found by: call frame info

9 libc-2.15.so!new_do_write [fileops.c : 537 + 0x11]

sp = 0x7e8b345c pc = 0x76b6abe5

Found by: stack scanning

Finally, run the following gdb command to dump 1024 words of the stack (i.e. potential addresses). In the output, for any value that corresponds to a known symbol, gdb will annotate it with the symbol's name in angle brackets. Knowing that, we can simply pipe the output to something (in this case, perl) to pull out any annotation it finds in the stack dump.