Proposed F18 feature: MiniDebugInfo

Jan Kratochvil jan.kratochvil at
Tue May 8 08:02:47 UTC 2012

On Tue, 08 May 2012 08:34:57 +0200, Alexander Larsson wrote:
> Its true that that is all the information you need from the
> process/core. But you need to have the rest of the information availible
> *somewhere*, such as on a global retrace server or just having it
> locally in the minidebuginfo. The later is far more robust and simple.
> It lets you directly get a reasonable backtrace given *only* the actual
> binaries in the running process.

Also during local crashes the daemon/process has been automatically updated in
the meantime on the disk while the older binary is still running - and it
crashes.  Only a few packages restart the daemon on its update (openssh does),
most packages do not (*).

In such case of stale running binary even local /usr/lib/debug is not enough
(and minidebuginfo sure also does not work), with ABRT Retrace Server it
always just works.

The unavailability of infrastructure is a myth, people have moved to Google
services from local programs and there are no complaints for "unavailability".

partial countercase to my argument: minidebuginfo could still work for the
main executable as during the crash dump it is still readable as /proc/PID/exe
and it could be extracted from it.  But for any .so libraries there is no
associated fd provided by kernel so in practice it is not applicable anyway.


(*) OT: Is not restarting a daemon on its update a packaging bug or not?

More information about the devel mailing list