I have Firefox in a debugger here with this crash. It appears to be showing up on crash-stats as well: http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=startswith&query=UnhookTextRunFromFrames&date=&range_value=1&range_unit=weeks&do_query=1&signature=UnhookTextRunFromFrames http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=startswith&query=UnhookTextRunFromFrames&date=&range_value=1&range_unit=weeks&do_query=1&signature=UnhookTextRunFromFrames%28gfxTextRun*%29 (not sure why we have two versions, with and without the arg list...) For example, this crash report has the exact same top few stack frames as mine: http://crash-stats.mozilla.com/report/index/1de4a0cb-7d95-4534-9788-679122090318 Looking at a few stacks, it looks like the same crash is happening on 1.9.0 as well. My stack: xul.dll!UnhookTextRunFromFrames() Line 349 + 0x2 bytes C++ xul.dll!FrameTextRunCache::NotifyExpired(gfxTextRun * aTextRun=0x0d228ef0) Line 390 C++ xul.dll!nsExpirationTracker<gfxTextRun,3>::AgeOneGeneration() Line 211 C++ xul.dll!nsExpirationTracker<gfxTextRun,3>::TimerCallback(nsITimer * aTimer=0x02259bb0, void * aThis=0x0074c6c0) Line 302 C++ xul.dll!nsTimerImpl::Fire() Line 428 + 0x7 bytes C++ nspr4.dll!_PR_MD_UNLOCK(_MDLock * lock=0x00714120) Line 347 C xul.dll!nsTimerEvent::Run() Line 522 C++ xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fca8) Line 511 C++ xul.dll!nsBaseAppShell::Run() Line 169 C++ xul.dll!nsAppStartup::Run() Line 193 C++ xul.dll!XRE_main(int argc=, char * * argv=, const nsXREAppData * aAppData=) Line 3223 C++ (there were frames below this, but they look like junk, I think VS got confused)

My debugger says it's crashed here: http://hg.mozilla.org/mozilla-central/annotate/b0aeb469c2d4/layout/generic/nsTextFrameThebes.cpp#l349 Although I think surely that means that it's actually crashed in ClearAllTextRunReferences, but I think that function has been inlined and the debugger doesn't actually know about it.

Sure looks like it: ClearAllTextRunReferences(static_cast<nsTextFrame*>(firstInFlow), aTextRun); 101A5644 mov eax,esi 101A5646 and dword ptr [eax+24h],0BFFFFFFFh 101A564D cmp dword ptr [eax+38h],edi 101A5650 jne UnhookTextRunFromFrames+3Ch (101A5664h) 101A5652 mov edx,dword ptr [eax] 101A5654 and dword ptr [eax+38h],0 101A5658 mov ecx,eax 101A565A call dword ptr [edx+98h] 101A5660 test eax,eax 101A5662 jne UnhookTextRunFromFrames+25h (101A564Dh) } else { I'm crashed at the second line of assembly there.

More context with the disassembly: http://pastebin.mozilla.org/636378

We're crashing because the textrun has a stale frame pointer in its userdata. It's remotely possible that this is bug 468491, which ccauses that.

FWIW, it also happens under Linux.

I can easily reproduce this (and a bunch of various other debug assertions) on Windows by visiting support.microsoft.com pages. Under WinDbg I can verify that the text frame pointer is stale (points to freed and reallocated memory!)

That's bad!

66 total crashes for UnhookTextRunFromFrames on 20090817 2 start up crashes inside 3 minutes 161.974 (days) total uptime for 61 of these crashes where user crashed within the last year 3823.65 (minutes) avg time since last crash 5 number of bogus time-since-last-crash reported for this signature distribution of versions where the crash was found on 20090817-crashdata.csv 27 Firefox 3.5.2 25 Firefox 3.0.13 3 Firefox 3.5.1 3 Firefox 3.0 2 Firefox 3.0.8 1 Firefox 3.5 1 Firefox 3.0.6 1 Firefox 3.0.5 1 Firefox 3.0.4 1 Firefox 3.0.12 1 Firefox 3.0.1

Neil, can you identify a specific page on support.microsoft.com that crashes Firefox? I couldn't find one.

I was able to get a nightly from 2009-03-24 (1.9.1 branch) to crash using the testcase in bug 468491: https://bugzilla.mozilla.org/attachment.cgi?id=351936 I'm not sure if it's the same crash though, as we don't appear to store the symbols on Socorro for builds that old: 0d85da56-68de-41ce-b4de-25d252100201 I also wasn't able to do a debug build from the same time period because we depended on an older version of libpango at the time which I don't have on my system. How can we move this bug forward?

It happens in 3.6 and trunk builds. It is #7 top crasher in 4.0b8pre build for the last week. Signature UnhookTextRunFromFrames UUID b2894d81-d7ce-4c19-9554-48e992101012 Time 2010-10-12 05:35:12.367664 Uptime 1872 Last Crash 152175 seconds (1.8 days) before submission Install Age 82703 seconds (23.0 hours) since version was first installed. Product Firefox Version 4.0b8pre Build ID 20101011041543 Branch 2.0 OS Windows NT OS Version 5.1.2600 Service Pack 3 CPU x86 CPU Info GenuineIntel family 6 model 14 stepping 12 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x1ad127dc App Notes AdapterVendorID: 0000, AdapterDeviceID: 0000 Frame Module Signature [Expand] Source 0 xul.dll UnhookTextRunFromFrames layout/generic/nsTextFrameThebes.cpp:392 1 xul.dll FrameTextRunCache::NotifyExpired layout/generic/nsTextFrameThebes.cpp:432 2 xul.dll nsExpirationTracker<gfxTextRun,3>::AgeOneGeneration obj-firefox/dist/include/nsExpirationTracker.h:210 3 xul.dll do_GetWeakReference obj-firefox/dist/include/nsIWeakReferenceUtils.h:111 4 xul.dll nsExpirationTracker<gfxTextRun,3>::TimerCallback obj-firefox/dist/include/nsExpirationTracker.h:307 5 mozsqlite3.dll sqlite3VdbeExec db/sqlite3/src/sqlite3.c:63042 6 nspr4.dll PR_ExitMonitor nsprpub/pr/src/threads/prmon.c:132 7 xul.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:517 8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:547 9 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:134 10 xul.dll xul.dll@0xade623 11 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:219 12 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:202 13 xul.dll _SEH_epilog4 14 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 15 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:180 16 xul.dll xul.dll@0xade623 17 xul.dll nsAppShell::Run widget/src/windows/nsAppShell.cpp:243 18 nss3.dll pkix_pl_Pk11CertStore_CheckTrust security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_pk11certstore.c:94 More reports at: http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=3&range_unit=days&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=UnhookTextRunFromFrames

146 total crashes across releases including 52 crashes on 4.0b8pre yesterday. 20101011 146 64 3.6.102010091412, 52 4.0b8pre2010101104, 5 3.6.32010040108, 3 3.5.132010091412, 3 3.0.192010031422, 2 3.62010011514, 2 3.5.132010091413, 2 3.1b22008120108, 2 3.0b52008032620, 1 4.0b62010091408, 1 4.0b52010083108, 1 4.0b12010063014, 1 3.7a52010061006, 1 3.6.82010072215, 1 3.6.62010062523, 1 3.6.3plugin12010040510, 1 3.6.112010100108, 1 3.5.142010100117, 1 3.0b42008030714, 1 3.02008052906, The spike in build 2010101104 could be a regression, or it could be several instances of dups. I tried correlating the 4.0b8pre reports to CPU and App Notes details and it appears that most reports are unique indicating a stronger chance of a volume regression.

looking at the top of the stack changes to nsTextFrameThebes.cpp have landed in the past few days. diff browse annotate f9712e32abb8 2010-10-11 13:58 +1300 Matt Woodrow - Bug 594983. Look inside display sublists to determine whether there is text for the layer. r=roc,a=blocking diff browse annotate cc8777e97c21 2010-10-11 00:07 +0200 Mats Palmgren - Just switch to the new textrun for empty text frames. b=571995 r=roc a=blocking2.0:final diff browse annotate fa5ecde710e3 2010-10-08 15:49 -0400 Ehsan Akhgari - Bug 602141 - Right arrow navigation broken on later contenteditable content on single line; r=bzbarsky a=blocking-final+

The recent spike mentioned in the last 2 comments should be fixed by backing out bug 571995: http://hg.mozilla.org/mozilla-central/rev/9af1a5813a7b

> The recent spike mentioned in the last 2 comments should be fixed by backing > out bug 571995 I confirm that there have been no crashes from b8pre/20101013 build.

resolved fixed due to the spike being fixed by the back out of bug 571995 no longer needs to block 2.0. removing that nom.