This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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*

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 ), so that linking all applications with libcoredumper could be avoided.

But I'm going off-topic for this list. ;)

Cheers, Jean-Marc


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]