740319 - crash in nsXPCWrappedJS::Release @ nsThreadManager::GetMainThread

Status: RESOLVED DUPLICATE of bug 741056

(Core :: XPConnect, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[Patrick McManus [:mcmanus]]

maybe related to 738812?

Comment 2

[Patrick McManus [:mcmanus]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> That would seem to mean the statically allocated threadmanager is null

Could we be in the middle of shutdown or something?

Comment 4

[Patrick McManus [:mcmanus]]

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.