On Fri, 30 Mar 2012 09:09:51 -0400, bugzilla wrote:
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=789636
abrt-bot@… changed:
What |Removed |Added
Status|NEW |CLOSED Resolution| |DUPLICATE Last Closed| |2012-03-30 09:09:49
--- Comment #8 from abrt-bot@… 2012-03-30 09:09:49 EDT --- Backtrace analysis found this bug to be similar to bug #759143, closing as duplicate.
Bugs which were found to be similar to this bug: DeviceKit-disks: bug #579968 claws-mail: bug #696680, bug #749177 evince: bug #615380 evolution: bug #744469 evolution-data-server: bug #607960, bug #799718 evolution-exchange: bug #669649 gnome-shell: bug #759143, bug #781780 gvfs: bug #571349 pcmanfm: bug #789628 rhythmbox: bug #681163, bug #709834, bug #748661 xfce4-sensors-plugin: bug #772409
This comment is automatically generated.
*** This bug has been marked as a duplicate of bug 759143 ***
This one is highly suspicious. It would be better to not close it as duplicate so brutally. Interrupting network connection in Claws Mail causes problems somewhere in Claws Mail and/or libetpan IMAP access and crashes the app. It isn't related to the other bugs, IMO. Just the symptoms are similar due to memory management discovering the problem.
Michael Schwendt mschwendt@gmail.com writes:
On Fri, 30 Mar 2012 09:09:51 -0400, bugzilla wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=789636 *** This bug has been marked as a duplicate of bug 759143 ***
This one is highly suspicious. It would be better to not close it as duplicate so brutally. Interrupting network connection in Claws Mail causes problems somewhere in Claws Mail and/or libetpan IMAP access and crashes the app. It isn't related to the other bugs, IMO. Just the symptoms are similar due to memory management discovering the problem.
Agreed, this one looks like a false positive. We are going to fix the scripts to ignore glib memory management functions.
If you reopen the bug, it will not be touched by the scripts again. Please let us know if you see other suspicious actions.
Thanks for the feedback!
Karel
On 03/30/2012 05:00 PM, Karel Klíč wrote:
Michael Schwendtmschwendt@gmail.com writes:
On Fri, 30 Mar 2012 09:09:51 -0400, bugzilla wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=789636 *** This bug has been marked as a duplicate of bug 759143 ***
This one is highly suspicious. It would be better to not close it as duplicate so brutally. Interrupting network connection in Claws Mail causes problems somewhere in Claws Mail and/or libetpan IMAP access and crashes the app. It isn't related to the other bugs, IMO. Just the symptoms are similar due to memory management discovering the problem.
Agreed, this one looks like a false positive. We are going to fix the scripts to ignore glib memory management functions.
If you reopen the bug, it will not be touched by the scripts again. Please let us know if you see other suspicious actions.
I am suspecting this also to be a false positive: https://bugzilla.redhat.com/show_bug.cgi?id=806419 which was closed as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=707963)
Different OSes (F15, vs, F16), entirely different sets of packages involved, 10 months of Fedora history inbetween.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
I am suspecting this also to be a false positive: https://bugzilla.redhat.com/show_bug.cgi?id=806419 which was closed as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=707963)
Different OSes (F15, vs, F16), entirely different sets of packages involved, 10 months of Fedora history inbetween.
The bugs seem to be duplicates to me, although I do not know gstreamer internals. The crashing threads are identical in the backtraces, and it's the same application.
Do you think that the differencea in non-crashing threads are relevant in this case?
Karel
Karel Klíč wrote:
Please let us know if you see other suspicious actions.
https://bugzilla.redhat.com/show_bug.cgi?id=805736
I reopened the false "duplicates".
The backtrace here looks the same in all apps: __GI_raise triggered from the Qt event loop, but that's because the Qt event loop catches all exceptions and rethrows them after doing some cleanups. Without the terminal output (which ABRT is unable to capture), there's usually no way to know what the actual exception was (though in the Rosegarden4 case, it seems to originate from a different thread, which shows an interesting backtrace), but it's likely different in each of the apps.
Kevin Kofler
devel@lists.stg.fedoraproject.org