Re: how could gdb handle truncated core files?

[Jean-Marc Saffroy <saffroy at gmail dot com>]

On Wed, 27 Aug 2008, Paul Pluzhnikov wrote:

> You may also want to look at Google user-space coredumper:
>  http://code.google.com/p/google-coredumper/

Cool, this project seems to do what I need, with a limited memory 
footprint! :)

> 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*
> compressible).

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. ;)


Cheers,
Jean-Marc

--
saffroy@gmail.com