It looks like things have gone a bit awry with this triage: https://bugzilla.redhat.com/show_bug.cgi?id=575030
ABRT's automatically reported backtrace didn't include debugging symbols, but the triager used the stock message here:
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Stack_Tr...
I was going to change that stock response to advise triagers that they should not use it in the case of automatically generated backtraces from ABRT. ABRT should have installed the required debuginfo packages automatically, and the fact that it didn't means there's a bug in ABRT (or a supporting package).
I'm thinking the right thing for the triager to do is to apologize for the system not collecting enough information to diagnose the crash, and assign the bug to ABRT (or the appropriate supporting package) so that future crashes can be diagnosed properly. Does that sound reasonable?
-B.
Hearing no objections, I updated the language at:
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Debuggin...
-B.
On Fri, 2010-04-02 at 16:19 -0400, Christopher Beland wrote:
It looks like things have gone a bit awry with this triage: https://bugzilla.redhat.com/show_bug.cgi?id=575030
ABRT's automatically reported backtrace didn't include debugging symbols, but the triager used the stock message here:
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Stack_Tr...
I was going to change that stock response to advise triagers that they should not use it in the case of automatically generated backtraces from ABRT. ABRT should have installed the required debuginfo packages automatically, and the fact that it didn't means there's a bug in ABRT (or a supporting package).
I'm thinking the right thing for the triager to do is to apologize for the system not collecting enough information to diagnose the crash, and assign the bug to ABRT (or the appropriate supporting package) so that future crashes can be diagnosed properly. Does that sound reasonable?
-B.
On Sat, 2010-04-03 at 12:07 -0400, Christopher Beland wrote:
Hearing no objections, I updated the language at:
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Debuggin...
-B.
On Fri, 2010-04-02 at 16:19 -0400, Christopher Beland wrote:
It looks like things have gone a bit awry with this triage: https://bugzilla.redhat.com/show_bug.cgi?id=575030
ABRT's automatically reported backtrace didn't include debugging symbols, but the triager used the stock message here:
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Stack_Tr...
I was going to change that stock response to advise triagers that they should not use it in the case of automatically generated backtraces from ABRT. ABRT should have installed the required debuginfo packages automatically, and the fact that it didn't means there's a bug in ABRT (or a supporting package).
I'm thinking the right thing for the triager to do is to apologize for the system not collecting enough information to diagnose the crash, and assign the bug to ABRT (or the appropriate supporting package) so that future crashes can be diagnosed properly. Does that sound reasonable?
I was on vacation since Friday :)
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.
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:
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:
- 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). 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.
...just running "debuginfo-install" usually doesn't fix the problem. (ABRT attempts that automatically.)
I adjusted: https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Debuggin... again; further discussion is welcome if this is still unsatisfactory.
-B.
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:
- 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..
- 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 help...
I adjusted: https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Debuggin... again; further discussion is welcome if this is still unsatisfactory.
-B.
-
Adam Williamson -
Christopher Beland -
Jiri Moskovcak