Changing stock response re: lack of debugging symbols with ABRT

Jiri Moskovcak jmoskovc at
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 
different backtraces

> 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
>> available.
>> 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.
> -B.

More information about the test mailing list