This is the mail archive of the
mailing list for the GDB project.
Re: how could gdb handle truncated core files?
- From: Paul Koning <Paul_Koning at dell dot com>
- To: saffroy at gmail dot com
- Cc: gdb at sourceware dot org
- Date: Wed, 27 Aug 2008 12:04:06 -0400
- Subject: Re: how could gdb handle truncated core files?
- References: <Pine.LNX.email@example.com>
>>>>> "Jean-Marc" == Jean-Marc Saffroy <firstname.lastname@example.org> writes:
Jean-Marc> Hi, For now, gdb does not seem to be able to do anything
Jean-Marc> useful with a truncated core file on Linux (ie. what you
Jean-Marc> get when your process dies and the core size limit is not
Jean-Marc> 0 but less than the size of the process).
Jean-Marc> In a number of cases, I think it would be nice to be able
Jean-Marc> to at least get a stack trace, and examine local
Jean-Marc> variables. This could require a limited amount of data to
Jean-Marc> be dumped by the kernel.
I've generally had good success (on a different OS) with partial
corefiles. As you said, the issue isn't in GDB, the issue is that the
partial corefile has to have the right subset of data in it.
Jean-Marc> ...In search of a solution, I patched my Linux kernel so that
Jean-Marc> dumping a core would start with the segments that hold a
Jean-Marc> stack (assuming user stack pointers are valid): thus these
Jean-Marc> segments have a chance of being dumped before the core
Jean-Marc> limit is reached.
Jean-Marc> This approach gives interesting results with a (very
Jean-Marc> simple) single threaded process. However, my attempts with
Jean-Marc> a multithreaded process failed, like this:
Jean-Marc> $ gdb <binary> <core> GNU gdb 6.8 <snip> This GDB was
Jean-Marc> configured as "x86_64-unknown-linux-gnu"... Cannot access
Jean-Marc> memory at address 0x2aaaaabc29c8 (gdb) bt #0
Jean-Marc> 0x00002aaaaabc9345 in ?? () #1 0x00000000400179f0 in ?? ()
Jean-Marc> #2 0x0000000000000000 in ?? ()
Jean-Marc> That is: - gdb does not load symbols from binaries - as a
Jean-Marc> result, gdb does not detect threads (because IIRC
Jean-Marc> libthread_db would be loaded when some libpthread.so
Jean-Marc> symbols are detected in the process) - the backtrace seems
Jean-Marc> incorrect: if I have a "full" core dump, gdb shows the
Jean-Marc> following stack trace:
I'm not particularly familiar with how shared library support works in
Linux. The address that's giving you trouble is a shared library
address, not an address in your main binary (or its data space). As a
guess, the problem is that there's an additional bit of critical data
that needs to be in your corefile: the tables that tell GDB what
shared libraries are loaded by the process, and to what addresses.