Re: how could gdb handle truncated core files?

[Paul Koning <Paul_Koning at dell dot com>]

>>>>> "Jean-Marc" == Jean-Marc Saffroy <saffroy@gmail.com> 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.

       paul