When reporting a bug from a crash, the bug is made private and a file called CoreDump.gz. The Bug Triage documentation says the following:

If the crash still has a CoreDump.gz attachment, then it was not possible to automatically get a fully symbolic stack trace and check for duplicates.

Stacktrace.txt seems readable by a human. How can I understand the meaning of a stack trace. CoreDump withing CoreDump.gz does not seem human readable. What is a "fully symbolic stack trace"? What is the difference between a "fully symbolic stack trace" How do I view the contents of a CoreDump file? (tried 'cat', but it's not clean)

1 Answer 1


Coredump.gz is the (compressed) memory accessible by the program that crashed. It is a binary file. Coredumps are a treasure trove, with all sorts of private data to be mined.

Coredumps can be viewed by running 'gdb':

gdb --core=mycoredump

Of course, you will still need the debug packages associated with this core.

You can, then, generate a stacktrace by:

(gdb) bt

to generate a stacktrace of the current thread -- without parameter resolution --, or

(gdb) thread apply all bt full

to generate a stacktrace of all threads in the coredump, with parameter resolution.

stacktrace and full stacktraces show the control flow within a program. For Python, the top of the stacktrace shows the oldest call, with the most recent at the bottom; for pretty much everything else, the top is the most recent call, and the bottom the oldest.

A full stacktrace will not only show the flow, but also the parameter's values. This is where we usually find private data -- for example, say you see a function called "validatePassword" with a parameter called "Password", and a value of "MySecretPassword"...

Stacktraces are usually only helpful if the debug packages are installed (so that the stack frames can be resolved into something we can easily read). Analysis of a stacktrace will require one to have the sources that were used to build this specific program instance.

  • CoreDump is a binary file, but how to you view it? Stacktraces are only helpful if debug packages are installed, then why does apport report it otherwise?
    – komputes
    Sep 30, 2011 at 19:33
  • 1
    The CoreDump file isn't meant to be viewed, it's meant to be used for debugging in gdb. You need to have a machine running the same version of the software (and all dependencies) generating the crash and having the debug packages, then you can use what Carlos posted above to get the stack trace.
    – stgraber
    Sep 30, 2011 at 19:38
  • 2
    Now as to how why it's still relevant for apport, it's because apport has a bunch of "retracers" that grab your coredump, install the debug packages on a box in the DC and then attach the full stacktract to the bug report.
    – stgraber
    Sep 30, 2011 at 19:39
  • Additional Documentation: gnu.org/software/gdb/documentation
    – komputes
    Sep 30, 2011 at 19:52
  • Additional Documentation: unknownroad.com/rtfm/gdbtut/gdbtoc.html
    – komputes
    Sep 30, 2011 at 20:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .