Bug 608266

Created attachment 427075 [details]
File: backtrace

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. closed app using x in corner after watching flash video 
2.
3.

The ABRT directed me to this bug. It happened when I had two or more windows of SM opened and closed one of them. Then in a little while the SM crashed (not a big problem as the session restore function worked perfectly).

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. Browser stops if there are flash objects on the browsed page
2.
3.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. opened seamonkey
2. changed router setting
3. opened tab to test setting
4. closed seamonkey

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. Open several tabs in Seamonkey browser
2. close one or more or close Seamonkey
3.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. Open several tabs in Seamonkey browser
2. close one or more or Seamonkey
3.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1.Open several tabs in Seamonkey browser
2. Close one or more tabs or close browser
3.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


Comment
-----
I had quite a few tabs open and clicked file quit then relied to save the open tabs.  It went away and a hit the swap drive for some time then pranged.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1.Running Seamonkey v2.05 with latest Java-RE 1.6u21
2.After testing a page with java content, system fails
3.


Comment
-----
Java RE was manually installed with new symlinks to /usr/bin/

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1.stop Seamonkey
2.
3.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. Start Seamonkey
2. Cruise the web, whatever
3. When done with Seamonkey, click off of it. Watch it crash.


Comment
-----
Pretty evident in the steps above what I did. This has been a bone of contention for a while now. Thanks.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. Start Seamonkey
2. Surf the web, whatever
3. Close Seamonkey. It crashes.


Comment
-----
There's nothing more to say. You start it, you stop it, it crashes. This happens every time I run it now. :(

I have just noticed that it doesn't do this anywhere near as much if I use the File menu, and go to Quit rather than clicking off with the X.

Can anyone confirm?

tested and I confirm

Wondering if that would really be all there is to it? The X? It still does it here and there with File/Quit, just nowhere near as much.

(In reply to comment #16)
> Wondering if that would really be all there is to it? The X? It still does it
> here and there with File/Quit, just nowhere near as much.    

Mine crashes regularly closing tabs or sometimes just switching between tabs. I'd love to get as far as using "File/Quit"!

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1. I had 5 tabs open in Seamonkey
2. Clicked to block someone on Twitter.
3. Seamonkey crashed.


Comment
-----
N/A - described in steps to reproduce. Seamonkey randomly crashes on me and shuts down out of the clear blue sky.

Package: seamonkey-2.0.5-1.fc13
Architecture: i686
OS Release: Fedora release 13 (Goddard)


How to reproduce
-----
1.Close browser window
2.
3.


Comment
-----
Closed browser window that had 3-4 tabs open, at least one of which had Flash animation content.  This seems to be a common element of all the Seamonkey crashes I experience.

This bug is still very much alive and kicking. I count 20 instances in my abrt log, and I am missing two or three due to abrt log full (I have increased max log size twice).

I have just searched and found from my second distro, Arch Linux, that there is a very similar bug filed on Seamonkey for it.

A workaround was posted here: http://bugs.archlinux.org/task/19005?string=seamonkey&project=1&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

"Seamonkey (and mozilla in general) ships with its own (stable, tested, holy, etc) version of cairo. You can switch between the bundled and system version with the --enable-system-cairo (or so) in mozconfig. I've found out that removal of this parameter and thus usage of the internal cairo library fixes the issue."

Hope this helps. It appears that upstream isn't exactly moving on this, and neither is Fedora. It's something to try for now.

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.

Thank you for taking the time to report this bug. Updates to this package have been released since it was first reported. If you have time to update the package and re-test, please do so and report the results here. You can obtain the updated package by typing 'yum update' or using the graphical updater, Software Update.


Disable extensions, plugins and non-default themes. Clear cookies and cache. Exit the browser completely.  Then restart the browser and attempt to replicate the crash.


#3  <signal handler called>
No symbol table info available.
#4  0x00848416 in __kernel_vsyscall ()
No symbol table info available.
#5  0x00e05d31 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        resultvar = <value optimized out>
        resultvar = <value optimized out>
        pid = 16134132
        selftid = 15839
#6  0x00e0760a in abort () at abort.c:92
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0xbf92ee14, sa_sigaction = 
    0xbf92ee14}, sa_mask = {__val = {13462100, 3214077448, 11352660, 0, 
    3077495888, 5, 0, 1, 3077531664, 134796564, 3076431936, 2647685136, 
    3214077368, 13721591, 2662335712, 3076434604, 1024, 0, 3214077520, 
    13046676, 3214077448, 3214077460, 2662761472, 2662761472, 3077531664, 0, 
    3076431936, 13498296, 13894011, 14496328, 14496328, 2662761472}}, 
          sa_flags = -1080889736, sa_restorer = 0x9ef00058}
        sigs = {__val = {32, 0 <repeats 31 times>}}
#7  0x00d180d6 in IA__g_logv (log_domain=0x472714 "Gdk", 
    log_level=<value optimized out>, format=0x4900f3 "%s", args1=
    0xbf92f33c "") at gmessages.c:549
        depth = 1
        domain = 0x0
        data = 0x0
        log_func = 0xd17630 <IA__g_log_default_handler>
        domain_fatal_mask = 5
        masquerade_fatal = <value optimized out>
        test_level = <value optimized out>
        was_fatal = 0
        was_recursion = 0
        i = <value optimized out>
#8  0x00d18107 in IA__g_log (log_domain=0x472714 "Gdk", log_level=
    G_LOG_LEVEL_ERROR, format=0x4900f3 "%s") at gmessages.c:569
        args = <value optimized out>
#9  0x0045ae93 in gdk_x_error (display=0xb7449000, error=0xbf92f42c)
    at gdkmain-x11.c:466
        buf = 
    "RenderBadPicture (invalid Picture parameter)", '\000' <repeats 19 times>
        msg = <value optimized out>
#10 0x06831a34 in bonobo_x_error_handler (display=0xb7449000, error=




-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Going through the Abrt log I can see that Seamonkey crashed 9 times over the last 7 days on this PC. Still I am not much bothered by this, as usually (but not always) the crashes happen when I am exiting the program, and I do not seem to lose any data. (I did not however do specific tests without extensions or cookies as recommended because I do need them for normal operation.)

It still crashes on me out of the clear blue sky. I've gotten to where I don't bother with abrt any more. Just updated today, it updated to 2.0.6, when 2.0.8 is out (I am on 2.0.8 in Arch), and it still crashes quite a bit.

That's my 2 cents, I've given up with it.

To Fedora's credit, it does do it in Arch, too, on 2.0.8.

I had been using 2.0.6. 

I have just updated to 2.0.8 from the F13 updates-testing repo. I stopped and restarted seamonkey four times and there was no crash. This is encouraging, but does not yet prove that the problem is solved. I will wait and see.

Looking at the list of changes since 2.0.6, there was this bug fixed in 2.0.7 that may possibly explain the crashes:
https://bugzilla.mozilla.org/show_bug.cgi?id=575836

I am not sure, however, because there is a lot to read in that bug and I don't have time to read it all.

Abrt log tells me that seamonkey crashed four times over the last 6 days with 2.0.8. This is a bit better than 2.0.6, though I am not sure if the difference is statistically significant.

I have now built seamonkey 2.0.8 from upstream sources. I will see if I have better luck with that. If I do that might mean a packaging issue. If I don't then it could mean a hardware-specific issue (and there are some, for example F13 compiz does not work on my Intel graphics PC).

I have had a full week without any SeaMonkey crash using my own build from upstream sources, so this seems to fix the crash problem. I don't know what is the problem with the Fedora package that causes crashes, most likely is related to some library incompatibility.

In case anyone wants to build from upstream sources these are some suggestions:

How to build:
https://developer.mozilla.org/En/Developer_Guide/Build_Instructions

One of the C files does not build in Fedora 13. To fix it do this:
In mozilla/toolkit/crashreporter/google-breakpad/src/common/linux/file_id.cc
Add a new line to include directives at top:
--
#include <sys/stat.h> 
--

And this is my .mozconfig:
----
mk_add_options MOZ_CO_PROJECT=suite
ac_add_options --enable-application=suite
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/suite-opt
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-static --disable-libxul
ac_add_options --disable-tests
----

Hmm, it may be that this bug is a duplicate of bug 602437 and if so it could be closed.

This was fixed long ago so I am closing it.