This is the mail archive of the
mailing list for the GDB project.
Re: how could gdb handle truncated core files?
On Wed, 27 Aug 2008, Paul Pluzhnikov wrote:
You may also want to look at Google user-space coredumper:
Cool, this project seems to do what I need, with a limited memory
It is often easier to play with than to boot custom kernels,
I'm not fond of custom kernels either. Should a clean kernel patch have
sufficed, I would have pushed for its inclusion in the mainline.
and it already has support for prioritisation of what is dumped,
as well as compression of the core (core files are often *extremely*
This prioritisation seems to be a simple and efficient way of reducing the
core size to something usable in the use cases I mentioned.
- gdb does not load symbols from binaries
The problem here most likely is that _r_debug.r_map was not found
in the (truncated) core. Without it, GDB can't know which libraries
were loaded, hence can't load unwind info for libpthread, hence
can't produce correct stack trace.
Indeed, that's certainly the problem! Thanks for pointing out. It seems
that coredumper's prioritisation works well enough that it does not need
to care about this level of detail directly.
Maybe the kernel could use the same approach, or a separate program could
trim full core dumps on the fly (see "Piping core dumps" in
http://lwn.net/Articles/280959/ ), so that linking all applications with
libcoredumper could be avoided.
But I'm going off-topic for this list. ;)