Bug 543517

Summary:	ABRT isn't merging duplicate backtraces
Product:	[Fedora] Fedora	Reporter:	Dave Malcolm <dmalcolm>
Component:	abrt	Assignee:	Jiri Moskovcak <jmoskovc>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	anton, beland, dfediuck, dvlasenk, iprikryl, jmoskovc, kklic, mnowak, npajkovs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-01-04 15:50:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dave Malcolm 2009-12-02 15:11:01 UTC

Description of problem:
I'm receiving numerous backtraces assigned to "python" via abrt (see bug 533521 for the rfe to assign them to the package owning the script that's crashing)

However, ABRT doesn't seem very smart about finding duplicates.

For example, bug 543286 shows a segfault inside qt's python bindings.

Bug 543317 shows the same segfault, but with (presumably) richer debuginfo.

Why did ABRT not mark these as being the same segfault?  Looking at the whiteboard, they have different hashes.

Ideally, when a backtrace is generated with the same symbols but with richer debuginfo, it should be submitted to the first bug, rather than opening a new one.

(I'm currently receiving a lot of ABRT backtraces, and doing this manually isn't going to scale up)

Comment 1 Jiri Moskovcak 2009-12-03 10:16:14 UTC

Hi,
I have written a patch for #533521 and now it's in the testing phase, so you should be soon freed of bugs caused by extensions. And for duplicate checking - it's quite hard to recognize if two backtraces are dupes when one is with debug symbols and the other without. If you have some hints on this it would be more than welcome.

Thank you,
Jirka

Comment 2 Jiri Moskovcak 2009-12-03 10:30:20 UTC

I just reproduced it and and it happens only if gui fails to run the daemon (you can see that the main window is empty). I make gui to refuse start in this case.

Jirka

Comment 3 Jiri Moskovcak 2009-12-03 12:07:51 UTC

Oops, this comment belongs to another BZ.

Comment 4 Christopher Beland 2010-01-04 15:50:06 UTC

There's hints on bug 525649, which is making the same request.  Marking as duplicate, I guess.

*** This bug has been marked as a duplicate of bug 525649 ***