437021 - Firefox periodically SEGFAULTs under Linux

Status: RESOLVED DUPLICATE of bug 397474

(Firefox :: General, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080526 SeaMonkey/1.1.9
Build Identifier: Unclear; a Firefox 3.0 prerelease compiled from the CVS source circa May 6 2008

I typically run Firefox for days at a time.  I am running the Firefox 3.0 prerelease.  Sometimes after days of use it will SEGFAULT which usually generate a fairly useless IMO BugBuddy report.  In this case, I happened to be running gdb attached to Firefox, in a attempt to learn more about Bug #263160 (which nobody seems to care about) and was able to obtain a stack trace series directly during the SEGFAULT.

The bug may have been associated with the Gmail Javascripts as I use Firefox exetensively for reading my Gmail account.  Also of use may be the information that shortly before the SEGFAULT, my gmail account through Firefox was refusing to accept input.  I could enter To: lines and Subject: lines but I could not enter any text in the message box itself.  I have seen this behavior multiple times with Gmail and Firefox though reproducing it is not easy.

Reproducible: Sometimes

Steps to Reproduce:
1. Extensive use of Firefox with gmail over a multi-day period.
2. Perhaps, a requirement for throwing the "Gtk/Gdk -- Window unexpectedly destroyed" bug -- see Bug #263160, because gmail was routinely hitting breakpoints in gdb associated with that bug.
Actual Results:  
Firefox SEGFAULTs and aborts invoking the BugBuddy tracing function.

Expected Results:  
Firefox should never SEGFAULT.

Trace from gdb will be attached.

It does create the need to restart Firefox, which depending on the number of open windows can take 10-15 minutes (which is filed as yet another bug).

Comment 1

[Robert Bradbury]

Attachment: Gdb trace during catching of a SEGFAULT

As documented, a catching of the Firefox 3.0 segmentation fault in gdb.

Comment 2

[timeless]

http://www.mozilla.org/unix/debugging-faq.html

you need to install debugging symbols for firefox.

if you got firefox from your vendor, there may be a -debug or -dbg package available (you'll want it and similar packages for all dependencies including cairo/gtk/glib/xlib).

if you bulit it yourself, you'll need to try again, --disable-strip, --enable-debug(ger-info-modules)

Comment 3

[Robert Bradbury]

Firefox is built with both --disable-strip and --disable-strip-libs.  And
indeed the binary is 133 megabytes, some 12 times the size of the normal
firefox-bin as distributed by Gentoo.  The symbols are there, and indeed gdb
appears to be able to find and set breakpoints in the firefox code.  Why the
backtraces do not work better is unclear to me though I suspect it may be
related to Firefox's use of shared library code and/or the dynamic mapping of
shared libraries.

I have gotten better stack traces with other versions of Firefox 2.0 that
required hacking together a gcc load script that built an almost fully static
firefox-bin [1] (it could not be done with the firefox "configure" file as
distributed).  But it was such a hellish exercise that I haven't wanted to try
it again with Firefox 3.0.

One could add to the bug list "firefox cannot be compiled as a completely
static" image if you like.  If someone could tell me precisely *who* is the person who added "--enable-static" to the configuration script and did not understand what the term really meant, I would really like to speak with them.  Because if and when I ever have children I want to send them to a place as far away from the college that educated them as possible.


1. I mean no libmozjs.so, no libxpcom_core.so, and all almost all of the other
shared object libraries found in /usr/lib/firefox on a typical Linux
installation.  There were still a couple of security related libraries that I
could not figure out how to get rid of, but I managed to get rid of most of the
rest.  It can be strongly argued that on a single-user Linux system where
Firefox is the primary application used by the user that there should be *no*
shared libraries as the opening of additional files, handling the symbol
relocation, etc. associated with them is nothing but a waste of time.  When I
startup firefox, it should be as fast as possible.  Because as documented in
another bug, I am typically restarting a complex session (see Bug #396375 and/or Bug #402867 and/or Bug #413390) and it takes 10-15+ minutes of maximum CPU use to get the session reestablished.

Comment 4

[vitone]

I think this is the same issue that I'm running into.

Firefox3 randomly crashes with a SIGSEGV but usually only with certain sites - most recently and consistently with http://www.pcworld.com/article/id,146496/article.html# while navigating through the article.  It seems that having multiple tabs open is a requirement for reproducing this bug.

I'm going to attach a backtrace but I may be missing some libs.

uname -a:
Linux agentorange 2.6.24.7-20080603A #2 SMP PREEMPT Tue Jun 3 10:39:03 EDT 2008 i686 pentium4 i386 GNU/Linux

Comment 5

[vitone]

Attachment: SIGSEGV backtrace

Comment 6

[vitone]

Attachment: backtrace w/ debug

backtrace using firefox 3.0rc1 built from source with --enable-debug --disable-strip

Comment 8

[Robert Bradbury]

I am not so sure that this is a duplicate bug for 397474.  The libraries being worked with were gtk+-2.12.9 and glib 2.16.3.  And I was definitely not doing a print preview,  And if indeed it is an X windows library bug, where is the citation of the bug being filed with them?

Citing a bug as being a different organization's problem does little good unless you give them the information to fix it.

Comment 9

[Robert Bradbury]

I take back some of my comments.  The bug (or at leas some aspects of the bug) are being worked on under Gnome bug #482531.  The comments in the gnome bug filing are particularly informative "Basically mozilla is destroying windows from their paint handler, which is kind of evil."  Which if I speculate may be the source of the "Window unexpectedly destroyed" messages, implies to me that there is a fundamental problem in how mozilla/firefox are using (or abusing) the windows system (or perhaps in a desire for different windows handling capabilities -- but that is a specification issue that I don't want to go into).

The fundamental problem remains *which* gtk+ version should be installed for Firefox to avoid the SEGFAULTs!  And be aware that this has to be a recommendation that applies across all Linux distributions.