1

I'm collecting stacktraces from very large coredumps via /proc/sys/kernel/core_pattern. The following questions suggest using /proc/pid/core_filter to reduce the size of large coredumps:

Minimal core dump (stack trace + current frame only)

Selective core dump in Linux - How can I select the dumped sections?

Is it possible to get a Linux coredump that only contains callstack, threads, and local variables?

But, when setting core_filter to '0', the resulting coredump is no longer meaningful to gdb's bt command.

So, I have the following two part question:

1) Is there a tool besides gdb which can extract the stacktrace from these minimal coredumps?

2) Is it possible to parse an ELF Core file to remove the heap segments? This question: What and where are the stack and heap? seems to indicate this might be possible.

Thanks!

Community
  • 1
  • 1
matthewatabet
  • 1,463
  • 11
  • 26
  • It shouldn't be super difficult to do that. Grab the ELF spec, use `readelf` on some existing core dump files, and see if you can make a selective copy of one that omits the program segments that you don't care about. – Kerrek SB Nov 21 '14 at 18:46
  • @KerrekSB Sounds good - but, how do I identify which segments I don't care about? – matthewatabet Nov 21 '14 at 18:51
  • Well, the program header tells you the virtual address and the size of the segment... does that help? – Kerrek SB Nov 21 '14 at 18:54
  • @KerrekSB hmmm... locating the segments and the virtual address ranges of the segments is not a problem. My question is, how do I know which segments contain heap data and which contain stack data? Hope that clarifies things. Thanks! – matthewatabet Nov 21 '14 at 18:55
  • 1
    On my 64-bit system, the heap segments seem to start at "0x00007f2xxxxxxxxx", and the stack is at "0x00007fffxxxxxxxx" -- look for the read-writable pages. – Kerrek SB Nov 21 '14 at 18:59
  • @KerrekSB I ran readelf on a few cores and it's still not quite clear to me what you mean -- are you saying that the segments with flags RW are the heap? For me, those segments have a wide range of addresses. Would it be possible to provide some more details on what you're doing, possibly as a full answer to the question? – matthewatabet Nov 21 '14 at 19:19

1 Answers1

1

But, when setting core_filter to '0', the resulting coredump is no longer meaningful to gdb's bt command.

Note that for a dynamically-linked binary, GDB backtrace needs to know about all shared libraries that appear in the stack trace (so it can find corresponding unwind descriptors).

For a "normal" core file, this info is in heap. Dropping heap from core then damages info shared, which in turn makes backtrace that has any shared libraries non-working.

You may be able to turn off bits 0 and 1 (anonymous private and shared mappings, which would cover heap) and still get a usable core if you turn on bit 3 (which would cover text of shared libraries, and which is normally not necessary, but is made necessary by dropping heap).

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Thanks for the info! I tried setting core_filter to 24 (0x18) but the core was still unusable by `gdb bt`. The additional insight was helpful though. – matthewatabet Nov 24 '14 at 20:54
  • I found this paper: http://www.researchgate.net/publication/251890419_On_reducing_of_core_dump_file_size which keeps just the program segment of the stack. I'm doubtful though that would work on x86_64 -- what do you think? – matthewatabet Nov 25 '14 at 00:36