Greg's firefox crashes

I've been using firefox for years now, and I can't say I like it very much. I've continually complained about its shortcomings. It reminds me of Jawaharlal Nehru's quote:

Democracy is good. I say this because other systems are worse.

The same seems to apply to firefox. I keep hoping that people will fix the bugs, misfeatures and performance problems in newer versions, but it doesn't seem to be happening. There's evidence that it's getting worse. Since upgrading to release 4 I have been having daily crashes. On this page I'm collecting information about the crashes. I haven't raised a bug report because it's clear to me that the evidence isn't sufficient.

Does this happen to other people? It seems not. There are a number of differences in the way I use firefox:

It's the FreeBSD version. This alone isn't a sufficient explanation, since other people use firefox on FreeBSD without this level of problems, but it may be a contributing factor.
I display many ~~high~~medium-resolution photos, which firefox frequently renders glacially slowly, suggesting that the code is suboptimal and thus not used much.
I don't use tabs, which I consider just to be a workaround for the lack of a sensible window manager in most environments. In particular, I frequently access different windows concurrently. This could trigger race conditions in the code that normally wouldn't get a chance to show themselves.

The following starts as an excerpt from my diary:

Sunday, 5 June 2011

Diary entry

Firefox continues to crash. Today I ran ps -l against the process every second, and caught the output when it died. An extract:

UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 1004 54918 54586 0 44 0 1038764 741776 ucond S 7 41:01.34 /usr/local/lib/firefox/firefox-bin 1004 54918 54586 0 44 0 1038764 715868 - T 7 41:01.98 /usr/local/lib/firefox/firefox-bin 1004 54918 54586 0 44 0 1038764 727948 - TL 7 41:02.03 /usr/local/lib/firefox/firefox-bin 1004 54918 54586 0 44 0 1038764 727672 - TL 7 41:02.10 /usr/local/lib/firefox/firefox-bin ... 1004 54918 54586 0 44 0 1038764 779036 - T 7 41:03.62 /usr/local/lib/firefox/firefox-bin

The first line shows it operating normally. Virtual size is 1038764 kB, about the size it often is when it dies. The status field is the most interesting: S means that it's sleeping for less than 20 seconds, which is pretty normal. T is stopped (which I've also seen in the top output), and the L after it means that pages are locked in core, for example for I/O. So this looks like the time it took to dump core, about 40 seconds (I haven't shown all the output). And the core dump?

=== grog@dereel (/dev/pts/12) ~ 14 -> gdb /usr/local/lib/firefox/firefox-bin firefox-bin.core Core was generated by `firefox-bin'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/firefox/libxul.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox/libxul.so ... hundreds of lines more of loading symbols from files without symbols (gdb) bt #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in XRE_LockProfileDirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called> #4 0x8297061a in std::vector<bool, std::allocator<bool> >::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #5 0x8255120a in mozilla::layers::LayerUserData::~LayerUserData () from /usr/local/lib/firefox/libxul.so #6 0x825517bf in mozilla::layers::LayerUserData::~LayerUserData () from /usr/local/lib/firefox/libxul.so #7 0x82d8fcfc in js::JSProxyHandler::isOuterWindow () from /usr/local/lib/firefox/libxul.so #8 0x82d8df44 in js::JSProxyHandler::isOuterWindow () from /usr/local/lib/firefox/libxul.so ... #13 0x82da26be in js::JSProxyHandler::isOuterWindow () from /usr/local/lib/firefox/libxul.so #14 0x823d433f in XRE_GetFileFromPath () from /usr/local/lib/firefox/libxul.so #15 0x823dcd06 in XRE_GetFileFromPath () from /usr/local/lib/firefox/libxul.so #16 0x823dd93a in XRE_GetFileFromPath () from /usr/local/lib/firefox/libxul.so ... #33 0x830a1bd8 in NS_NewLocalFile_P () from /usr/local/lib/firefox/libxul.so #23 0x08048dfd in ?? () #24 0x00000001 in ?? () ... #46 0x08048a98 in ?? () During symbol reading, Incomplete CFI data; unspecified registers at 0x08048a85. Previous frame inner to this frame (corrupt stack?)

It's round about here that I begin to lose interest. The whole thing, from top to bottom, seems to be in libxul.so, whatever that is, and the functions seem to delight in calling themselves recursively—if I can trust the backtrace. But the names seem to suggest that the problem is related to JavaScript and not to the size of the process image. I wonder what else I can do without getting my hands dirty.

Tuesday, 7 June 2011

Diary entry

Firefox continues to crash at far-too-frequent intervals. I'm collecting stack backtraces. This one was much shorter:

(gdb) bt #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in XRE_LockProfileDirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called> #4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0xb5ff1fc4 in ?? ()

So again it seems to be in JavaScript. This one was an eBay page. But I don't think it's the page itself: I suspect that it's more likely to be some race condition in the browser code, since it frequently happens when I do things with many different windows.

Wednesday, 8 June 2011

Diary entry

The next firefox crash happened under similar circumstances to the last: I was trying to leave feedback on eBay. Is this also JavaScript? It's not in member functions, but it still appears to be JavaScript:

(gdb) bt #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in XRE_LockProfileDirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called> #4 0x831dcfae in JSCompartment::wrap () from /usr/local/lib/firefox/libxul.so #5 0xbd5c3048 in ?? () #6 0x00000000 in ?? () #7 0xbfbfa798 in ?? () #8 0x82cba12d in xpc_LocalizeContext () from /usr/local/lib/firefox/libxul.so

Thursday, 9 June 2011

Diary entry

I'm beginning to see some sort of pattern in the firefox crashes. First, they all come out of the signal handler, so the first four stack frames are always the same:

My guess is that the XRE_LockProfileDirectory () frame is saving the configuration before accepting the inevitable and re-raising the signal (in this case SIGSEGV). But once again it was in JavaScript code, and once again the backtrace terminated abnormally:

#4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0xac6176c4 in ?? () #6 0xbfbfac7c in ?? () #7 0x00000000 in ?? ()

Clearly 0x00000000 is an invalid return address; less clearly, so is 0xbfbfac7c: on this architecture, that's in the stack (at the time of the crash, $esp contained the value 0xbfbfa7ec), and 0xac6176c4 looks interesting too. That could be a red herring, or it could be smashing its stack. Is JavaScript a red herring too?

Saturday, 11 June 2011

Diary entry

Today's firefox crash backtrace had a certain sense of déjà vu:

#4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0x950e5244 in ?? () #6 0xbfbfac7c in ?? () #7 0x00000000 in ?? ()

It's not identical to the previous one, but the trap occurs at exactly the same location, 0x8322f682 in js::MarkContext (). I suppose it's about time to take a look at the source, but not today.

Sunday, 12 June 2011

Diary entry

The firefox crashes seem to be converging. This is the third day that it crashed in the same place:

#4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0xa4267ac4 in ?? () #6 0xbfbfac7c in ?? () #7 0x00000000 in ?? ()

It's interesting that frame 6 again shows the same address on the stack. Maybe there's some trampoline in the previous stack frame, and it's normal that the remainder of the trace is invalid.

Another thing that I noted was the number of threads: one initial thread and 23 others. Does firefox start one thread per window? I tried another instance with only a single window and shot it down with kill -11. The results were interesting: 18 threads instead of 24, suggesting that no, the number of threads and the number of windows are not directly related. But maybe there's some race condition in the code that only gets triggered with multiple windows, and which doesn't show up with the “there can only be one” processing of tabs.

Monday, 13 June 2011

Diary entry

Today's firefox crash was once again the same:

#4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0x0d873744 in ?? () #6 0xbfbfac7c in ?? () #7 0x00000000 in ?? ()

This is no longer news; I'll keep information on a separate page.

Tuesday, 14 June 2011

Diary entry

this looks the same as the last few.

(gdb) bt #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in xre_lockprofiledirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called:gt; #4 0x8322f682 in js::markcontext () from /usr/local/lib/firefox/libxul.so #5 0xafe8e8c4 in ?? () #6 0xbfbfac7c in ?? () #7 0x00000000 in ?? () #8 0x8294fec4 in std::vector >::_m_fill_insert () from /usr/local/lib/firefox/libxul.so previous frame inner to this frame (corrupt stack?)

Wednesday, 15 June 2011

Diary entry

The stack back trace here is clearly the same as before, but for once i wasn't doing lots of things concurrently. it's interesting that these crashes all seem to happen about the same time of day, so i'm now keeping track of the size and modification timestamps of the dumps.

(gdb) bt #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in XRE_LockProfileDirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called:gt; #4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0x095bbfc4 in ?? () #6 0xbfbfac7c in ?? () #7 0x00000000 in ?? () #8 0x8294fec4 in std::vector >::_M_fill_insert () from /usr/local/lib/firefox/libxul.so Previous frame inner to this frame (corrupt stack?) === grog@dereel (/dev/pts/17) ~ 9 -> l firefox-bin.core -rw------- 1 grog lemis 1014624256 Jun 15 11:23 firefox-bin.core

Thursday, 16 June 2011

Diary entry

Friday, 17 June 2011

Diary entry

Back to the normal backtrace:

-rw------- 1 grog lemis 1258074112 Jun 17 09:09 firefox-bin.core #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in XRE_LockProfileDirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called> #4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0x9bd69144 in ?? () #6 0xbfbfa12c in ?? () #7 0x00000000 in ?? () #8 0x8294fec4 in std::vector<bool, std::allocator<bool> >::_M_fill_insert () from /usr/local/lib/firefox/libxul.so Previous frame inner to this frame (corrupt stack?)

I wasn't even in the room when it crashed.

-rw------- 1 grog lemis 1035608064 Jun 17 17:37 firefox-bin.core #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in XRE_LockProfileDirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called> #4 0x8322f682 in js::MarkContext () from /usr/local/lib/firefox/libxul.so #5 0x9ae56b44 in ?? () #6 0xbfbfacfc in ?? () #7 0x00000000 in ?? () #8 0x8294fec4 in std::vector<bool, std::allocator<bool> >::_M_fill_insert () from /usr/local/lib/firefox/libxul.so Previous frame inner to this frame (corrupt stack?)

Attempting update of multiple eBay pages.

Saturday, 18 June 2011

Diary entry

-rw------- 1 grog lemis 1455394816 Jun 18 11:04 firefox-bin.core #0 0x845a8147 in kill () from /lib/libc.so.7 #1 0x845a80a6 in raise () from /lib/libc.so.7 #2 0x823cb55a in XRE_LockProfileDirectory () from /usr/local/lib/firefox/libxul.so #3 <signal handler called> #4 0x831acd3d in JS_GetStringCharsZAndLength () from /usr/local/lib/firefox/libxul.so #5 0x82e9c84e in js::JSProxyHandler::isOuterWindow () from /usr/local/lib/firefox/libxul.so #6 0x82e9e8cb in js::JSProxyHandler::isOuterWindow () from /usr/local/lib/firefox/libxul.so #7 0x82e9ea53 in js::JSProxyHandler::isOuterWindow () from /usr/local/lib/firefox/libxul.so #8 0x82e86292 in js::JSProxyHandler::isOuterWindow () from /usr/local/lib/firefox/libxul.so #9 0x98db4140 in g_NPN_Invoke () from /home/grog/.mozilla/plugins/npwrapper.libflashplayer.so #10 0x98db4f3d in handle_NPN_Invoke () from /home/grog/.mozilla/plugins/npwrapper.libflashplayer.so #11 0x98dbd169 in _rpc_dispatch () from /home/grog/.mozilla/plugins/npwrapper.libflashplayer.so #12 0x98dbd3fd in _rpc_dispatch_until () from /home/grog/.mozilla/plugins/npwrapper.libflashplayer.so #13 0x98dbef67 in _rpc_method_wait_for_reply_valist () from /home/grog/.mozilla/plugins/npwrapper.libflashplayer.so #14 0x00000000 in ?? ()