Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: ABRT fails to find duplicates sometimes... Some ideas: - only 5-6 functions from stack may be used for hash - http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 362678 [details] sample backtrace from gtk application I'd like to raise importance of this issue. Looks like abrt takes into the account all frames found in the stracktrace. This is wrong as there may be infinite number of ways to get to the crash in glib-based applications (using glib mainloop) as event handling is (probably) done in idle. For example, look at the attached backtrace. It goes from gtk_main() to g_main_loop_run(), processing some X events (xlib), ending with calling exit handlers (frame #16), which involves a lot of other things before abort () is actually called. The real cause here lies in between frames #20 and #18. Now, this is maybe wrong example due to exit handlers involved in the backtrace, but imagine that most of X protocol stack is async. Trace will be always different, chance to correctly finding duplicate is very low. This makes ABRT nearly unusable for glib and gtk applications, we're receiving a lot of duplicates for the same thing. For now, blacklisting apps linking to libglib-2.0.so might be a solution until this is fixed.
Typical example of differences in backtraces with random glib and gtk stuff: https://bugzilla.redhat.com/attachment.cgi?id=362493 vs. https://bugzilla.redhat.com/attachment.cgi?id=362963
from 524416: Description of problem: Bug 522853 and bug 522854 are IMHO duplicates, but abrt didn't figured it out.
*** Bug 524416 has been marked as a duplicate of this bug. ***
Please don't steal my bug. This one is about better strack-trace analyze (select propper thread, print relevant info to bugzilla and so on). Not about duplicates.
For me as a abrt developer, "analyze backtrace better" is too vague. "Analyze backtrace better" is what way? I changed the title so that it actually says what should be achieved according to your own bug descripton. Did I misunderstand you?
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 543517 has been marked as a duplicate of this bug. ***
Carrying forward info from bug 543517 (just marked as a dup of this one), another specific example of where two backtraces that ought to be marked as duplicates aren't being matched as such: > For example, bug 543286 shows a segfault inside qt's python bindings. > Bug 543317 shows the same segfault, but with (presumably) richer debuginfo. It could be argued that we're seeing different underlying reasons for the lack of duplicate-matching, of course.
*** Bug 541442 has been marked as a duplicate of this bug. ***
From dup 541442: Description of problem: I have developed to my jetpack script (http://git.fedorahosted.org/git/?p=triage.git;a=blob_plain;f=jetpack/bugzillaBugTriage.js;hb=jetpack look around function parseBacktrace) which parses attached backtrace and provides to the comment box most relevant part (if available). See bug 541173 comment 3 for an example. I guess it could be useful if abrt provided something similar automagically. Maybe shorter? How many frames are most useful? And no, I don't think should REPLACE attaching full all-threads backtrace, just SUPPLEMENT it. The attached backtrace should remain, IMHO.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
ABRT's backtrace analysis is probably good enough now, esp. in the latest-git (next version).
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Fixed in abrt-1.1.14-1