Closed Bug 441133 Opened 12 years ago Closed 7 years ago

Segmentation fault on closing tab with Google Ajax application [@ FrameTextRunCache::NotifyExpired]


(Core :: Layout: Text and Fonts, defect, critical)

Not set



Tracking Status
blocking2.0 --- -
status2.0 --- wanted


(Reporter: winkelklammern, Assigned: roc)



(Keywords: crash, intermittent-failure)

Crash Data

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008061015 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008061015 Firefox/3.0

When I attempt to close a tab with a Google Ajax application while I'm logged in to Google, Firefox immediately exits with a segmentation fault.

Reproducible: Always

Steps to Reproduce:
1. Login to Google with a Google account.
2. Open an Ajax application such as Google Reader ( oder Google Maps (
3. Open a second tab
4. Reactivate the Google tab
5. Close the active tab
Actual Results:  
Firefox exited.
Console output: Segmentation fault

Expected Results:  
Closed the tab and take me back to the second tab I opened
Only if there is no third tab open, that is.
I can confirm this. Firefox 3 crashes almost every time I close a Gmail tab! :-(

Even with a third tab. It doesn't make difference to me.

I tried both the official build and a custom one.

Linux 2.6.25 here.
Please do this:
1. Use an official binary build.
2. Start this build in the Firefox safemode (
3. Let this Firefox build crash
4. send a report from the hopeful opened Mozilla crash reporter.
5. start firefox again and type about:crashes as URL, post 1-3 Crash IDs in this bug
Severity: normal → critical
Component: Tabbed Browser → General
Keywords: crash
QA Contact: tabbed.browser → general
Cannot reproduce with current nightly build.

I tried with my version in safe mode. The crash reporter doesn't open.
Please disable the flash plugin and try it again.
Flash is known to break the crashreporter on win32 could be the same for linux.
I was already using an official build and submitting crash reports.
I forgot to say that sometimes my firefox doesn't crash... It just hangs forever.

However, here are the IDs for the times it eventually crashed in safe mode:

c17f3651-4107-11dd-9ee9-001321b13766	06/23/2008	11:35 AM
8edaba97-4107-11dd-97cb-001cc45a2c28	06/23/2008	11:34 AM
04a334e6-4107-11dd-bab9-001cc45a2c28	06/23/2008	11:30 AM

I'd like also to note that crash it's not always immediate... Sometimes FF crashes about 20-100 seconds after I close a tab containing an AJAX app.
roc, see also Bug 392777 Bug 394208 Bug 419342 Bug 414559
i'm picking the first crash because it's slightly more exciting.
Signature	FrameTextRunCache::NotifyExpired(gfxTextRun*)
UUID	c17f3651-4107-11dd-9ee9-001321b13766
Time	2008-06-23 02:35:39-07:00
Uptime	81
Product	Firefox
Version	3.0
Build ID	2008052912
OS	Linux
OS Version	0.0.0 Linux 2.6.25-quaqo #1 SMP PREEMPT Wed Jun 18 21:23:01 CEST 2008 i686 GNU/Linux
CPU	x86
CPU Info	GenuineIntel family 10 model 15 stepping 6
Crash Reason	SIGSEGV
Crash Address	0xb7751a19
Crashing Thread
Frame 	Module 	Signature 	Source
0 	FrameTextRunCache::NotifyExpired 	mozilla/layout/generic/nsTextFrameThebes.cpp:374
1 	nsExpirationTracker<gfxTextRun, 3u>::AgeOneGeneration 	nsExpirationTracker.h:210
2 	nsExpirationTracker<gfxTextRun, 3u>::TimerCallback 	mozilla/layout/generic/nsTextFrameThebes.cpp:298
3 	nsTimerImpl::Fire 	mozilla/xpcom/threads/nsTimerImpl.cpp:400
4 	nsTimerEvent::Run 	mozilla/xpcom/threads/nsTimerImpl.cpp:490
5 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:510
6 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:227
7 	nsBaseAppShell::Run 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170
8 	nsAppStartup::Run 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
9 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3170
10 	firefox-bin 	main 	mozilla/browser/app/nsBrowserApp.cpp:158

reporter, each of your crashes is different, here are the other two:

Signature	[@ 0xaf58a005 - CSSParserImpl::ParseURL]
UUID	8edaba97-4107-11dd-97cb-001cc45a2c28

Signature	[@ js_DropObjectMap]
UUID	04a334e6-4107-11dd-bab9-001cc45a2c28
Component: General → Layout: Fonts and Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Summary: Segmentation fault on closing tab with Google Ajax application → Segmentation fault on closing tab with Google Ajax application [@ FrameTextRunCache::NotifyExpired]
Version: unspecified → Trunk
Yep. I noted that sometimes "Crash Report" says the report had been sent, but it doesn't appear in about:crashes... This means the report hadn't been sent or it just isn't shown in the list?
Can you look in your profile directory, there should be a folder "crash reports" with a "submit.log"

 0!FrameTextRunCache::NotifyExpired(gfxTextRun*) [nsTextFrameThebes.cpp:2e213af0a405 : 420 + 0xd]
    eip = 0xb74bdfbf   esp = 0xbfbb1cc0   ebp = 0xbfbb1cd8   ebx = 0xb7ec1868
    esi = 0xad4c7dc0   edi = 0xb2e16dc0   eax = 0x00000000   ecx = 0x00000000
    edx = 0xad844000   efl = 0x00210292
 1!nsExpirationTracker<gfxTextRun, 3u>::AgeOneGeneration() [nsExpirationTracker.h : 210 + 0xa]
    eip = 0xb74bd886   esp = 0xbfbb1ce0   ebp = 0xbfbb1d08
 2!nsExpirationTracker<gfxTextRun, 3u>::TimerCallback(nsITimer*, void*) [nsTextFrameThebes.cpp:2e213af0a405 : 299 + 0x8]
    eip = 0xb74bd8d3   esp = 0xbfbb1d10   ebp = 0xbfbb1d28
 3!nsTimerImpl::Fire() [nsTimerImpl.cpp:2e213af0a405 : 427 + 0x7]
    eip = 0xb7b7128b   esp = 0xbfbb1d30   ebp = 0xbfbb1d58
 4!nsTimerEvent::Run() [nsTimerImpl.cpp:2e213af0a405 : 519 + 0x8]
    eip = 0xb7b719ab   esp = 0xbfbb1d60   ebp = 0xbfbb1d78
 5!nsThread::ProcessNextEvent(int, int*) [nsThread.cpp:2e213af0a405 : 527 + 0xa]
    eip = 0xb7b6e5fc   esp = 0xbfbb1d80   ebp = 0xbfbb1db8
 6!NS_ProcessNextEvent_P(nsIThread*, int) [nsThreadUtils.cpp : 230 + 0xd]
    eip = 0xb7b3d283   esp = 0xbfbb1dc0   ebp = 0xbfbb1de8
 7!nsBaseAppShell::Run() [nsBaseAppShell.cpp:2e213af0a405 : 170 + 0x9]
    eip = 0xb7aa609e   esp = 0xbfbb1df0   ebp = 0xbfbb1e08
 8!nsAppStartup::Run() [nsAppStartup.cpp:2e213af0a405 : 193 + 0x5]
    eip = 0xb7976fd6   esp = 0xbfbb1e10   ebp = 0xbfbb1e28
 9!XRE_main [nsAppRunner.cpp:2e213af0a405 : 3392 + 0xb]
    eip = 0xb72a6a4b   esp = 0xbfbb1e30   ebp = 0xbfbb24a8
10  firefox-bin!main [nsBrowserApp.cpp:2e213af0a405 : 156 + 0xe]
    eip = 0x080495aa   esp = 0xbfbb24b0   ebp = 0xbfbb2508
11 + 0x1604f
    eip = 0xb65ba050   esp = 0xbfbb2510   ebp = 0xbfbb2578

Linux mozilla-central talos nochrome on 2009/08/07 08:32:29
Whiteboard: [orange]
Ever confirmed: true
I'm able to reproduce this problem on trunk build always, when login to Gmail first time.... and popup notification box appearing

Valgrind output
==29100== Thread 1:
==29100== Invalid write of size 4
==29100==    at 0x9101967: FrameTextRunCache::NotifyExpired(gfxTextRun*)
==29100==    by 0x9101783: nsExpirationTracker<gfxTextRun,
3u>::TimerCallback(nsITimer*, void*) (nsExpirationTracker.h:210)
==29100==    by 0x9AF46FA: nsTimerImpl::Fire() (nsTimerImpl.cpp:427)
==29100==    by 0x9AF47F8: nsTimerEvent::Run() (nsTimerImpl.cpp:519)
==29100==    by 0x9AF09DD: nsThread::ProcessNextEvent(int, int*)
==29100==    by 0x9AAFFF8: NS_ProcessNextEvent_P(nsIThread*, int)
==29100==    by 0x99E0230:
==29100==    by 0x9B459F8: MessageLoop::RunInternal() (
==29100==    by 0x9B45A2B: MessageLoop::RunHandler() (
==29100==    by 0x9B45AB9: MessageLoop::Run() (
==29100==    by 0x996E6A6: nsBaseAppShell::Run() (nsBaseAppShell.cpp:175)
==29100==    by 0x980CC6F: nsAppStartup::Run() (nsAppStartup.cpp:192)
==29100==    by 0x8EDDAF5: XRE_main (nsAppRunner.cpp:3702)
==29100==    by 0x8049C70: ??? (in
==29100==    by 0x54CB5B4: (below main) (in
Is that an opt build or a debug build? Can you reproduce in a debug build? If you can, is the assertion on line 152 firing?

Could you try changing the assertion on line 152 to code that does a printf if the condition fails, and then (in a debug or opt build with symbols) set a breakpoint on that printf and reproduce the problem? I'd like to know what's in *state and what's in aObj.

My guess is that aObj is dangling because we deleted the textrun, but maybe not since Valgrind should have complained about that earlier. If it is dangling, you could add a printf to gfxTextRun's destructor to log textrun destruction and try to get some idea of when the textrun is being destroyed without removing it from the nsExpirationTracker. Every textrun that's destroyed should be removed from the tracker.
Assignee: nobody → roc
blocking2.0: --- → ?
blocking2.0: ? → -
status2.0: --- → wanted
Crash Signature: [@ FrameTextRunCache::NotifyExpired]
Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that:
* Haven't changed in > 6months
* Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb}
* Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive.

I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases).

Sorry for the spam! Filter on: #FFA500
Closed: 7 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.