Bug 216652

I can confirm this bug - it's getting increasingly frustrating.

Running FC6 x86_64 and Firefox 1.5.0.8-1.fc6.x86_64.

I also receive no errors on program termination.

Confirm this bug on FC6 i386 and Firefox 1.5.0.8.  It is very frustrating.

same thing happens if you try to "save as"
ftp://ftp.iasi.roedu.net/mirrors/centos.org/4.4/isos/i386/CentOS-4.4-i386-binDVD.torrent

i've launched from terminal and i get:

$ firefox --verbose

(Gecko:24376): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion
`GDK_IS_COLORMAP (cmap)' failed

(Gecko:24376): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT
(object)' failed

(Gecko:24376): Gdk-CRITICAL **: gdk_colormap_get_visual: assertion
`GDK_IS_COLORMAP (colormap)' failed
/usr/lib/firefox-1.5.0.8/run-mozilla.sh: line 131: 24376 Segmentation fault    
 "$prog" ${1+"$@"}
$

I can confirm similar behaviour with FC6, x86_64 1GB RAM. firefox-1.5.0.9

rob, do you have 32-bit or 64-bit? I cannot reproduce this on 32-bit.

32 bit (see original post - "i386").  I didnt think about running verbose.  I'm
not using ff1.5 any more (using 2.0.0.1 with relatively few problems) but will
reinstall 1.5 and play about see if i can replicate it again.

Seeing the same random crashing of Firefox happening on my Compaq nx6325 (AMD
Turion64 x2). Firefox seems to crash more frequently when clicking on hyperlinks
that call another application such as a hyperlink for a torrent calling the
BitTorrent client or a hyperlink calling the PDF reader for a PDF etc. I don't
remember this being a problem during earlier versions of the kernal if that has
anything to do with it. 
Additional Data: 2.6.20-1.2944.fc6 #1 SMP Tue Apr 10 17:46:00 EDT 2007 x86_64
x86_64 x86_64
Interestingly enough when I yum -info firefox it shows the two recent versions
of Firefox installed. 1.5.0.9 & 1.5.0.10 in 32 and 64 bit versions. I have not
done any custom complilations of Firefox. Everything was updated with the yum
utility.

Martin, can you look at this?  I believe this is also causing a bunch of
Epiphany crashes.  http://bugzilla.gnome.org/show_bug.cgi?id=413350

Can you please try to get a bactrace? how-to is here -
http://people.redhat.com/stransky/mozilla

The gnome bug has tons of backtraces and about 30+ dupes.  They are all on FC6
x86-64.

aha, okay.

yeah, finally I can reproduduce this crash (
http://bugzilla.gnome.org/show_bug.cgi?id=413350)

Created attachment 153965 [details]
proposed patch

Kai,

what do you think about this patch? 

The Main thread is registered by nsIThread::SetMainThread (and via.
PR_SetThreadPrivate) and it's released in _PR_DestroyThreadPrivate (during
exit()), right?

So I think this hack in nsThread::Shutdown should not be there.

*** Bug 238770 has been marked as a duplicate of this bug. ***

(In reply to comment #12)
> yeah, finally I can reproduduce this crash (
> http://bugzilla.gnome.org/show_bug.cgi?id=413350)

Martin, did you reproduce the crash using Firefox or Epiphany? Or both?

Ralf reported this bug in November 2006 against Firefox and SeaMonkey.

I do NOT see crashes using Firefox or SeaMonkey.


The Gnome bug got filed on 2007-03-01.
All duplicate bug reports are against Epiphany, and they all got filed after
2007-03-01.

I CAN reproduce the epiphany crash.

I conclude the epiphany crash got introduced on or closely before 2007-03-01, by
new FC 6 update packages.


I suspect these are different bugs.


(In reply to comment #14)
> So I think this hack in nsThread::Shutdown should not be there.

If you hover this code in:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/threads/nsThread.cpp&rev=1.60&cvsroot=/cvsroot
you'll see that it got added 7 years ago.

I think it's more likely the bug is caused by something else.


Martin, did you actually test your proposed patch?
Did it fix the crash for you?

If this call is the cause of the crash, why is nsThread::Shutdown not listed in
the stack traces?

While I'm still interested in the answer to above questions, maybe Martin is
right that his patch can help. I realize with NSPR 4.6.5 we added a patch that
makes thread cleanup work better.

NSPR 4.6.5 for FC6 got released by the end of february 2007, so it might be
related to the many crashes that got reported with epiphany starting in March.

However, it would not explain why Ralf crashed before that date.

I'm answering some of my own questions:

(In reply to comment #17)
> If this call is the cause of the crash, why is nsThread::Shutdown not listed in
> the stack traces?

Because probably nsThread::Shutdown called it first, and the NSPR thread cleanup
code (added with nspr-4.6.5.fc6) called it afterwards.

I have reopened bug 238770, because I know what caused it, it got introduced
after 2007-02-24 and it is a crash-on-exit only.

This bug is clearly something else, because Ralf experiences it in the middle of
his work, and he saw this bug 3 months earlier.

Comment 8 up to comment 19 in this bug really belong to bug 238770.
While Martin found the right place to fix this issue, I'll propose and explain a
different patch in bug 238770.

Anyway, I still can't reproduce the original bug. Closing a worksforme.
Reporter, please reopen and attach the backtrace when it appears again.

Martin, I think this upstream bug 413350
(http://bugzilla.gnome.org/show_bug.cgi?id=413350), which is a bug with most
duplicates I have seen in my life.

(In reply to comment #22)
> Martin, I think this upstream bug 413350
> (http://bugzilla.gnome.org/show_bug.cgi?id=413350), which is a bug with most
> duplicates I have seen in my life.

Matej, I think gnome 413350 is related to the "crash on exit" only.
We understand why it crashes on exit and have a fix, we just haven't pushed out
the fix to all channels yet.

This bug 216652 is about random crashes, in the middle of using Firefox, and for
this separate problem we don't yet understand why it happens.