It first appeared in 14.0a1/20120324 and is currently #20 top crasher in 14.0a1 over the last day. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab2ff3b5611f&tochange=df1f94b2bdee Signature nsThreadManager::GetMainThread(nsIThread**) More Reports Search UUID 5d9205f5-46d8-4f69-87ce-74a532120329 Date Processed 2012-03-29 11:38:32 Uptime 1646 Last Crash 1.6 hours before submission Install Age 3.0 hours since version was first installed. Install Time 2012-03-29 08:35:58 Product Firefox Version 14.0a1 Build ID 20120328115525 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 37 stepping 5 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x6 App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x0046, AdapterSubsysID: 7008103c, AdapterDriverVersion: 8.15.10.2413 D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ EMCheckCompatibility True Total Virtual Memory 4294836224 Available Virtual Memory 3618574336 System Memory Use Percentage 34 Available Page File 13113479168 Available Physical Memory 5498126336 Frame Module Signature Source 0 xul.dll nsThreadManager::GetMainThread xpcom/threads/nsThreadManager.cpp:284 1 xul.dll do_GetMainThread obj-firefox/dist/include/nsThreadUtils.h:225 2 xul.dll nsXPCWrappedJS::Release js/xpconnect/src/XPCWrappedJS.cpp:209 3 xul.dll nsXPTCStubBase::Release xpcom/reflect/xptcall/src/xptcall.cpp:65 4 xul.dll ReleaseObjects obj-firefox/xpcom/build/nsCOMArray.cpp:167 5 xul.dll nsVoidArray::EnumerateForwards obj-firefox/xpcom/build/nsVoidArray.cpp:722 6 xul.dll nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:132 7 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:182 8 xul.dll nsHttpHandler::NotifyObservers netwerk/protocol/http/nsHttpHandler.cpp:578 9 nspr4.dll _MD_CURRENT_THREAD nsprpub/pr/src/md/windows/w95thred.c:308 10 nspr4.dll PR_Unlock nsprpub/pr/src/threads/combined/prulock.c:347 11 xul.dll nsHttpChannel::OnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:4316 12 xul.dll nsInputStreamPump::OnStateStart netwerk/base/src/nsInputStreamPump.cpp:444 13 xul.dll nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:399 14 xul.dll nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:114 15 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:656 16 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:134 17 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:201 18 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:175 19 xul.dll nsBaseAppShell::Run widget/xpwidgets/nsBaseAppShell.cpp:189 20 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:267 21 xul.dll nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:295 22 xul.dll XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:3770 23 xul.dll XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:3847 24 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3923 25 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:107 26 firefox.exe __tmainCRTStartup crtexe.c:552 27 kernel32.dll BaseThreadInitThunk 28 ntdll.dll __RtlUserThreadStart 29 ntdll.dll _RtlUserThreadStart More reports at: https://crash-stats.mozilla.com/report/list?signature=nsThreadManager%3A%3AGetMainThread%28nsIThread**%29

maybe related to 738812?

not sure where to go with this one yet. The crashes generally involve deref of 0x6 (on 32 bit) in nsThreadManager::GetMainThread() but it isn't always from the same stack as in comment 0. That would seem to mean the statically allocated threadmanager is null, which doesn't make a lot of sense (the crash reports have a variety of uptimes). bug 741056 has the same regression range and also created some hard to grok stacks and was pretty common. A fix for that went to inbound this morning at the very least we can see if the crashes for this bug go down with the first nightly that contains that - though I'm looking for a firmer lead to explore.. cc:ing boris to tap his deep cross-component knowledge.

> That would seem to mean the statically allocated threadmanager is null Could we be in the middle of shutdown or something?

Crash stats report the last incident of this as the 04-05 build, previous to that it was quite common since the pipeline merge. bug 741056 fixed a problem with that merge and is the most likely candidate to have caused this (similar to how it is the root of 739142). if the crash stats hadn't cleared up it would still be possible that 738812 is the root cause. that patch hasn't been committed yet.