Proposed F18 feature: MiniDebugInfo

Jan Kratochvil jan.kratochvil at
Mon May 7 15:50:56 UTC 2012

On Mon, 07 May 2012 17:40:18 +0200, Lennart Poettering wrote:
> on the individual machine,

There is no backing reason for this requirement.  It does not matter where.

> without having to keep coredumps,

Core dump currently always have to be shortly stored on the disk anyway, even
for using minidebuginfo.  Backtracing crashed program without dumping its core
would be a different project.

> And currently we can't do this.

Unfortunately this is not possible with all your requirements due to:

 * Even the optimal full debuginfo size (Jakub's dwz) is still only IIRC ~50%
   of the current debuginfo size, which is still not suitable to install for
   every package on every machine.

 * Opinions to this item significantly differ but minidebuginfo-only
   backtraces are in many (IMO most) cases not usable for problem analysis.

> Having a centralized service that is bombared everytime any user of
> Fedora anywhere on the world runs into a coredump

There are some efforts from ABRT team to discard duplicate crashes already
before uploading them.

> You don't want to centralize dispatching of something that can happen
> a million times a second all around the world.

Unique crashes do not happen so often.

> Right now, it is easier to make sense of a kernel oops without any
> special tools,

Kernel is a very specific package and its behavior and coding style cannot be
automatically generalized to other packages.

> And that's something that needs fixing, and what Alex helps us to do.

I agree we should fix it but I believe there are better options to do so.

Primarily ABRT Retrace Server is already deployed and I still have not heard
why not to use its significantly better debug info backtraces quality compared
to this symtab-only poor backtraces.


More information about the devel mailing list