CODEWITHSUNDEEP
debugginggdb
Marcin
Marcin

Reputation: 422

Faster using of GDB to analyze core dump

I need to check stack trace after segfault. Loading symbols remain about 10 minutes. When I am trying to check coredump (gdb <program> -c <core>) I get: warning: core file may not match specified executable file. And then stack trace is:

(gdb) bt
#0  0x00007f96eab3d72a in ?? ()
#1  0x00007f96ec846239 in ?? ()
#2  0x0000000000006b04 in ?? ()
#3  0x00007fff64076500 in ?? ()
#4  0x00007fff64076570 in ?? ()
#5  0x00007f96ec846192 in ?? ()
#6  0x00007f96ba5144e0 in ?? ()
#7  0x0000000000549fa0 in ?? ()
#8  0x0000000000549fa8 in ?? ()
#9  0x0000000000549fa8 in ?? ()
#10 0x0000000000549fa8 in ?? ()
#11 0x0000000000000000 in ?? ()

It is possible to speedup checking stack trace after segfault?

Upvotes: 2

Views: 989

Answers (1)

Employed Russian
Employed Russian

Reputation: 213957

Loading symbols remain about 10 minutes.

Presumably that's because the "symbols" includes full debug info.

You didn't say what you want to analyze the core dump for. One usual requirement is to simply determine which function the core dump happened in, and that requires only the symbol table, not full debug info.

Therefore, it may be that what you want is:

cp a.out-full-debug a.out-symbols-only
strip -g a.out-symbols-only

# Symbol loading should be much quicker
gdb ./a.out-symbols-only ./core

Obviously, you only need to run strip once for any given build.

You also didn't say which compiler/OS you are using. If we assume a recent version of GCC or Clang, you could also drastically speed up GDB symbol loading by using separate debug info files, and -gsplit-dwarf -gdwarf-4 flags. See this answer.

Upvotes: 3

Related Questions