Changing stock response re: lack of debugging symbols with ABRT
jmoskovc at redhat.com
Mon Apr 19 08:22:02 UTC 2010
On 04/18/2010 07:42 PM, Christopher Beland wrote:
> The feedback I got was conflicting...
> On Tue, 2010-04-06 at 10:52 -0700, Adam Williamson wrote:
>> I'd say you're mostly on the right track, but I'd rather we explain to
>> the reporter how to manually install the correct debug packages (with
>> debuginfo-install) to generate a useful traceback for the crash
>> (debuginfo-install, then re-generate the crash report in abrt), and ask
>> them to report a bug against abrt _as well_. I don't think we want to
>> lose the initial crash report.
> Well, if the initial stack trace isn't useful for debugging, there
> doesn't seem to be much use in keeping it assigned to the crashing
> component. As Mads says:
- the current logic in ABRT will open a new bug if reporter recreates
the backtrace, as it doesn't recognize it as a duplicate because of
> On Thu, 2010-04-08 at 12:15 +0200, Mads Kiilerich wrote:
>> I would like to add that as far as I can see the lack of debug symbols
>> is usually due to a update of either the binary or the debuginfo,
>> causing a situation where debuginfo matching the core is simply not
>> So please consider:
>> 1. Don't blame abrt so much for the lack of debuginfo (even though they
>> should make it more clear why debuginfos was missing - and perhaps
>> provide this stock answer automatically).
- good idea, sometimes we know why it failed: e.g: old package..
>> 2. Don't push manual installation of debuginfo so hard. It will probably
>> be a waste of time and thus demotivating for the reporter. AFAIK it is
>> also not simple to create a new ABRT report which uses these debuginfos.
- what's so hard on pressing "Refresh" in ABRT's gui? it will recreate
the backtrace with the new debuginfo
- the problem is, that even if debuginfo-install installs some
additional debuginfo packages the backtrace might stay the same because
the debuginfo doesn't match the coredump ...
> ...just running "debuginfo-install" usually doesn't fix the problem.
> (ABRT attempts that automatically.)
- that's not true, ABRT uses different logic to find and install the
required debuginfo packages, so *sometimes* the debuginfo-install might
> I adjusted:
> again; further discussion is welcome if this is still unsatisfactory.
More information about the test