How to proceed with MiniDebugInfo
kklic at redhat.com
Thu May 24 15:06:44 UTC 2012
IMHO administrators would benefit much more from the minidebuginfo
feature than developers. The advantage for admins is that for every
crash the computer would also give a "name" of the crash. So it's
no longer just "httpd: Core dumped.", but you get a unique sequence
of functions (a "name") and you can talk about this particular crash
with other admins (it's no longer just "our webserver is randomly
crashing"), and search the Internet for other victims.
It would be very cool if the bottom of the stack (last few functions)
is printed to the terminal together with the usual "Core dumped."
For developers, it is unappealing to attempt fixing a bug just from
an ordered list of function names.
Alexander Larsson wrote:
> Now, I don't want to repeat everything said before about what
> minidebuginfo can do, but I'll give some short examples of things
> are nice to have and hard to do well without local debuginfo.
> * Write backtraces to syslog on coredumps
> * Allow ABRT to do better duplication matching (the ABRT developers
> want minidebuginfo!)
> * Always get some minimal level of backtrace quality, even for rpms
> built locally or from other repositories which are not availible
> on the retrace servers. (Assuming they are built on a F18 or later
> which has this feature.)
> * Do system wide profiling and tracing without having to install a
> of debuginfo.
> * Help developers by always having at least some level of debuginfo,
> even for e.g. uncommon dependencies that you don't typically have
> debuginfo for, or when you don't have a network connection to get
> debuginfo packages.
More information about the devel