On May 2, 2008, at 10:39 PM, David Timms wrote:
Kevin Kofler wrote:
special format for crash reports, it's just a GDB backtrace. If GDB
is not installed, KCrash just displays an error that no backtrace
could be obtained because GDB is not installed.
What would you think of that message instead stating some helpful
text, with a button to invoke PackageKit to install the good stuff
so that a useful backtrace could be generated ?
Is it too late to get a backtrace if you didn't already have gdb and
the needed -debuginfo's installed ?
No, as long as you have the right pieces of the core dump (or, y'know,
the whole thing). You can use the BuildIDs embedded in the core dump
to gather the exact binaries (and associated debuginfo) used in the
crash, and retrace the backtrace from there.
That's part of what the server side of Apport does - takes incomplete
crash dumps and retraces them. Then you can generate a hash of the
trace[1] and compare that to other known crash-hashes to get automatic
dup finding.
Actually, if possible you'd want to generate a hash of the *un-
retraced* dump too, and have the reporter app check the database of
known/frequently reported crashes *before* submitting. Then the user
gets:
"CRASHYAPP has just crashed. This is a known problem and is being
worked on by DISTRO developers. You can follow the progress of this
work here: BZLINK"
Wouldn't that be nice?
-w
[1] We'd want a special filter for the trace and/or a specialized hash
function to make sure that crash dumps that are *very* similar end up
with hashes that are similar or identical.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
