gdb - Remote Post-mortem coredump analysis without having exact debug symbols for shared system libraries -


how around problem? imagine thread crashes inside libc code (which system shared library) on computer1 , generates coredump. computer2 on coredump analysed might have different version of libc.

so:

  1. how important have same shared library on remote computer? gdb correctly reconstruct stacktrace without having exact same version of libc on conputer2?

  2. how important have correct debug symbols libc? gdb correctly reconstruct stacktrace without having exact same debug symbols on computer2?

  3. and "correct" way avoid debug symbol mismatch problem shared system libraries? me seems there no single solution solves problem in elegant way? maybe can share experience?

  1. it depends. on processors, such x86_64, correct unwind descriptors required gdb unwind stack. on such machine, analyzing coredump non-matching libc produce complete garbage.

  2. you don't need debug symbols libc stack trace. wouldn't file , line numbers without debug symbols, should correct function names (except when inlining has taken place).

  3. the premise of question wrong -- debug symbols have nothing this. "correct" way analyze coredump on c2, when coredump produced on c1, have copy of c1's libraries (in e.g. /tmp/c1/lib/...) , direct gdb use copy instead of c2's installed libc with

    (gdb) set solib-absolute-prefix /tmp/c1

command.

note: above setting must in effect before load core gdb. this:

gdb exe core (gdb) set solib-absolute-prefix /tmp/c1 

will not work (core read before setting in effect).

here right way:

gdb exe (gdb) set solib-absolute-prefix /tmp/c1 (gdb) core core 

(i've tried find reference on web, didn't).

what unwind descriptors?

unwind descriptors required when code compiled without frame pointers (default x86_64 in optimized mode). such code not save %rbp register, , gdb needs told how "step back" current frame caller frame (this process known stack unwinding).

why isn't c1's libc.so included in core?

the core file contains contents of writable segments of program address space. read-only segments (where executable code , unwind descriptors reside) not necessary -- read them directly libc.so on disk.

except doesn't work when analyze c1's core on c2!

some (but not all) operating systems allow 1 configure "full coredumps", os dump read-only mappings well, precisely can analyze core on machine.


Comments

Popular posts from this blog

asp.net - repeatedly call AddImageUrl(url) to assemble pdf document -

java - Android recognize cell phone with keyboard or not? -

iphone - How would you achieve a LED Scrolling effect? -