abrt 1.1.1 detected a crash. architecture: i686 Attached file: backtrace cmdline: /usr/lib/seamonkey-2.0.6/seamonkey-bin -mail comment: The problem is reproduced for version 2.0.6. component: seamonkey crash_function: nsProfileLock::FatalSignalHandler executable: /usr/lib/seamonkey-2.0.6/seamonkey-bin global_uuid: 6e4bcafe01ea4996abdc18cba711d07826f6e561 kernel: 2.6.33.6-147.fc13.i686.PAE package: seamonkey-2.0.6-1.fc13 rating: 4 reason: Process /usr/lib/seamonkey-2.0.6/seamonkey-bin was killed by signal 6 (SIGABRT) release: Fedora release 13 (Goddard) How to reproduce: Steps are the same as for versions 2.0.4 and 2.0.5
Created attachment 434021 [details] File: backtrace
seamonkey-2.0.6 crashes the same way as described in bug https://bugzilla.redhat.com/show_bug.cgi?id=583300
Package: seamonkey-2.0.6-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- Same as in every SM with F13's libcairo.
Package: seamonkey-2.0.6-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) Comment ----- crashes *after* closing program via [X]
Open several heavy pages and quickly close them one by one.
Package: seamonkey-2.0.6-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. Just close Seamonkey, seems to happen every time 2. 3.
Package: seamonkey-2.0.6-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. Open Seamonkey 2. Cruise the web 3. Close Seamonkey Comment ----- Same as always...
Package: seamonkey-2.0.6-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. I was just surfing the web with Seamonkey, and it crashed out of the clear blue sky. 2. 3. Comment ----- This is getting ridiculous.
I'm seriously beginning to think it's the upstream bug. It does this in my Arch Linux, too, and did it in Mandriva as well when I was on it.
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=522635 Bug was fixed long time ago in the trunk, but Fedora ships old SeaMonkey with new Cairo version. I can't understand why nothing is done about it in Fedora. SeaMonkey is absolutely unusable, crashing every 10th tab close, there are two patches in the bug + there's always possibility to use 2.1 alpha. Actually, I'm using 2.1a2 and 2.1a3 for the last month and it's rock stable in absolute terms, while the "stable" release you're using isn't at all. The only problem it has is combo buttons not expanding, you have to use keyboard to operate them. Probably something to do with being compiled by some robot on an ancient system, but I CBA to recompile SeaMonkey on Fedora :) AGAIN: Maintainters, why oh why can't we get one of the patches applied to SM and put to updates-testing? Or Koji? Or wherever? We're waiting MONTHS (bug was first reported in F13 RCs as bug 583300) for you to release a fix to make SM remotely usable, when patches seem available. Upstream is clearly not interested in supporting 2.0 on newer distros, so it really needs to be fixed downstream for now...
*** Bug 625971 has been marked as a duplicate of this bug. ***
This is getting way too ridiculous. Seamonkey, no matter what I do, crashes at least six times a day now with this. Fedora, please fix. Thank you.
@Leszek Matok, 2.x.x is no more stable for me than this is, and is so much more even like Firefox, it makes me want to scream. It's no solution here. Thanks anyway.
Sorry, meant the alpha.
I have added the option for --disable-system-cairo to Seamonkey 2.0.6's execution, I have 8 tabs open (have opened and closed a whole lot more than that), and Seamonkey hasn't crashed in a couple of hours at least. I've also closed it using the X with no crash. Just a heads up.
Adding it to execution arguments won't help (I actually tested just in case, but it crashed as usual after 20 or tabs closed), but rebuilding RPM with it should! :) Anyone able to provide a scratch build in Koji? I'm not going to install a million devel packages since for me, binary 2.1a from mozilla.org nightlies works 100% stable (unless Flash crashes it, but that's easy to work around, and that's only if you use Flash at all)
I forced myself to actually rebuild SeaMonkey with --disable-system-cairo. Wasn't that bad, took little over an hour to yum-builddep seamonkey, yum-downloader --source seamonkey, correct seamonkey-mozconfig with above option and rpm -bb seamonkey.spec. I'm writing this from SM 2.0.6 with 15 hours of uptime, so the work-around is working. As usual, I have to ask maintainers: why can't you put such build in updates-testing at least? That's a third known work-around now and nothing is being done...
I'm wondering how that worked for me then? I ran up to 25 tabs, closed them, opened them, the works. I stayed up for some 5 hours for the very first time with it.
*** Bug 628760 has been marked as a duplicate of this bug. ***
*** Bug 628757 has been marked as a duplicate of this bug. ***
Looks like it's not working any more. :P
I've removed the NEEDSINFO tag -- if it should still be here, can someone state what info is needed?
Also, why is this marked low importance?
I've noticed this here and at the Arch bugzilla both. When we file a bug, it doesn't give us the option of importance. Also, check to see if it was filed via ABRT - if it was, it was filed as auto-low importance and priority...
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.