This is the mail archive of the
mailing list for the GDB project.
how could gdb handle truncated core files?
- From: Jean-Marc Saffroy <saffroy at gmail dot com>
- To: gdb at sourceware dot org
- Date: Wed, 27 Aug 2008 17:21:22 +0200 (CEST)
- Subject: how could gdb handle truncated core files?
For now, gdb does not seem to be able to do anything useful with a
truncated core file on Linux (ie. what you get when your process dies and
the core size limit is not 0 but less than the size of the process).
In a number of cases, I think it would be nice to be able to at least get
a stack trace, and examine local variables. This could require a limited
amount of data to be dumped by the kernel.
I'm curious what could be done to improve this situation, because I see
two potential use cases:
- embedded systems developpers: sometimes it's hard to find enough space
to write your core file (eg. the application uses 80% of your RAM, and
your only writable filesystem is a tiny temporary RAM disk)
- parallel application developpers on large clusters: sometimes you use a
huge amount of RAM in a bunch of processes (eg. an MPI parallel program),
and dumping all that on your home directory will fill your disk quota
and/or keep your file server busy for a very long time
In search of a solution, I patched my Linux kernel so that dumping a core
would start with the segments that hold a stack (assuming user stack
pointers are valid): thus these segments have a chance of being dumped
before the core limit is reached.
This approach gives interesting results with a (very simple) single
threaded process. However, my attempts with a multithreaded process
failed, like this:
$ gdb <binary> <core>
GNU gdb 6.8
This GDB was configured as "x86_64-unknown-linux-gnu"...
Cannot access memory at address 0x2aaaaabc29c8
#0 0x00002aaaaabc9345 in ?? ()
#1 0x00000000400179f0 in ?? ()
#2 0x0000000000000000 in ?? ()
- gdb does not load symbols from binaries
- as a result, gdb does not detect threads (because IIRC libthread_db
would be loaded when some libpthread.so symbols are detected in the
- the backtrace seems incorrect: if I have a "full" core dump, gdb shows
the following stack trace:
#0 0x00002aaaaabc9345 in pthread_create@@GLIBC_2.2.5 ()
#1 0x00000000004005c8 in main (argc=<value optimized out>,
argv=<value optimized out>) at thrcore.c:24
So, I have the following questions to the community:
- what can I do (eg. in my kernel patch) to have gdb load symbols from
- do you have any comment on my approach? (eg. I *think* I've seen AIX
produce small dumps, but I have no idea how they do it, if it's a special
file format, etc.)
Thanks for your comments!