Proposed F18 feature: MiniDebugInfo

[Jan Kratochvil]

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.


Regards,
Jan


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