Closed Bug 505016 Opened 12 years ago Closed 7 years ago

crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] or [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]


(Core :: XPCOM, defect)

Not set



Tracking Status
blocking2.0 --- -
status1.9.1 --- wanted


(Reporter: wsmwk, Assigned: mrbkap)


(Keywords: crash, Whiteboard: [tbird crash])

Crash Data

crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)]

seen more with FF -**%29&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsXPCWrappedJS%3A%3AQueryInterface%28nsID%20const%26%2C%20void**%29

but there is also this Thunderbird crash...

nsXPCWrappedJS::QueryInterface	 js/src/xpconnect/src/xpcwrappedjs.cpp:173
canonicalize	xpcom/base/nsCycleCollector.cpp:1108
GCGraphBuilder::NoteXPCOMRoot	xpcom/base/nsCycleCollector.cpp:1330
XPCJSRuntime::AddXPConnectRoots	js/src/xpconnect/src/xpcjsruntime.cpp:437
nsXPConnect::BeginCycleCollection	js/src/xpconnect/src/nsXPConnect.cpp:573
nsCycleCollector::BeginCollection	xpcom/base/nsCycleCollector.cpp:2323
nsCycleCollector_beginCollection	xpcom/base/nsCycleCollector.cpp:2916
XPCCycleCollectGCCallback	js/src/xpconnect/src/nsXPConnect.cpp:391
js_GC	js/src/jsgc.cpp:3506
JS_GC	js/src/jsapi.cpp:2487
nsXPConnect::Collect	js/src/xpconnect/src/nsXPConnect.cpp:478
nsCycleCollector::Collect	xpcom/base/nsCycleCollector.cpp:2256
nsCycleCollector_collect	xpcom/base/nsCycleCollector.cpp:2904
nsJSContext::CC	dom/src/base/nsJSEnvironment.cpp:3419
nsJSContext::MaybeCC	dom/src/base/nsJSEnvironment.cpp:3471
nsJSContext::CCIfUserInactive	dom/src/base/nsJSEnvironment.cpp:3488
DocumentViewerImpl::LoadComplete	layout/base/nsDocumentViewer.cpp:1037
nsDocShell::EndPageLoad	docshell/base/nsDocShell.cpp:5243
nsWebShell::EndPageLoad	docshell/base/nsWebShell.cpp:1015
nsDocShell::OnStateChange	docshell/base/nsDocShell.cpp:5139
nsDocLoader::FireOnStateChange	uriloader/base/nsDocLoader.cpp:1235
nsDocLoader::doStopDocumentLoad	uriloader/base/nsDocLoader.cpp:858
nsDocLoader::DocLoaderIsEmpty	uriloader/base/nsDocLoader.cpp:763
nsDocLoader::OnStopRequest	uriloader/base/nsDocLoader.cpp:679
nsLoadGroup::RemoveRequest	netwerk/base/src/nsLoadGroup.cpp:688
nsDocument::DoUnblockOnload	content/base/src/nsDocument.cpp:7026
nsBindingManager::DoProcessAttachedQueue	content/xbl/src/nsBindingManager.cpp:978
nsRunnableMethod<nsBindingManager>::Run	nsThreadUtils.h:264
nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:510
NS_ProcessPendingEvents_P	nsThreadUtils.cpp:180
nsBaseAppShell::NativeEventCallback	widget/src/xpwidgets/nsBaseAppShell.cpp:121
nsAppShell::ProcessGeckoEvents	widget/src/cocoa/
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]	
-[NSApplication run]	
nsAppShell::Run	widget/src/cocoa/
nsAppStartup::Run	toolkit/components/startup/src/nsAppStartup.cpp:192
XRE_main	toolkit/xre/nsAppRunner.cpp:3279
main	nsMailApp.cpp:103
not much concern here for thunderbird ... only ~6 crashes in 6 months

example bp-c31ba322-2a67-4cb2-b58d-1c1d92090327
Module	Signature [Expand]	Source
0	thunderbird-bin	nsXPCWrappedJS::QueryInterface	js/src/xpconnect/src/xpcwrappedjs.cpp:173
1	libxpcom_core.dylib	canonicalize	xpcom/base/nsCycleCollector.cpp:1108
2	libxpcom_core.dylib	GCGraphBuilder::NoteXPCOMRoot	xpcom/base/nsCycleCollector.cpp:1330
3	thunderbird-bin	XPCJSRuntime::AddXPConnectRoots	js/src/xpconnect/src/xpcjsruntime.cpp:437
4	thunderbird-bin	nsXPConnect::BeginCycleCollection	js/src/xpconnect/src/nsXPConnect.cpp:573
5	libxpcom_core.dylib	nsCycleCollector::BeginCollection	xpcom/base/nsCycleCollector.cpp:2323
6	libxpcom_core.dylib	nsCycleCollector_beginCollection	xpcom/base/nsCycleCollector.cpp:2916
7	thunderbird-bin	XPCCycleCollectGCCallback	js/src/xpconnect/src/nsXPConnect.cpp:391
8	libmozjs.dylib	js_GC	js/src/jsgc.cpp:3506
9	libmozjs.dylib	JS_GC	js/src/jsapi.cpp:2487
10	thunderbird-bin	nsXPConnect::Collect	js/src/xpconnect/src/nsXPConnect.cpp:478
11	libxpcom_core.dylib	nsCycleCollector::Collect	xpcom/base/nsCycleCollector.cpp:2256
12	libxpcom_core.dylib	nsCycleCollector_collect	xpcom/base/nsCycleCollector.cpp:2904
13	thunderbird-bin	nsJSContext::CC	dom/src/base/nsJSEnvironment.cpp:3419
14	thunderbird-bin	nsJSContext::MaybeCC	dom/src/base/nsJSEnvironment.cpp:3471
15	thunderbird-bin	nsXMLHttpRequest::RequestCompleted	content/base/src/nsXMLHttpRequest.cpp:2407
16	thunderbird-bin	nsXMLHttpRequest::OnStopRequest	content/base/src/nsXMLHttpRequest.cpp:2343
17	thunderbird-bin	nsHttpChannel::OnStopRequest	netwerk/protocol/http/src/nsHttpChannel.cpp:4851
18	thunderbird-bin	nsInputStreamPump::OnStateStop	netwerk/base/src/nsInputStreamPump.cpp:576
19	thunderbird-bin	nsInputStreamPump::OnInputStreamReady	netwerk/base/src/nsInputStreamPump.cpp:401
20	libxpcom_core.dylib	nsInputStreamReadyEvent::Run	xpcom/io/nsStreamUtils.cpp:111
21	libxpcom_core.dylib	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:510
22	libxpcom_core.dylib	NS_ProcessPendingEvents_P	nsThreadUtils.cpp:180
23	thunderbird-bin	nsBaseAppShell::NativeEventCallback	widget/src/xpwidgets/nsBaseAppShell.cpp:121
24	thunderbird-bin	nsAppShell::ProcessGeckoEvents	widget/src/cocoa/
25	CoreFoundation	CoreFoundation@0x735f4	
26	CoreFoundation	CoreFoundation@0x73cd7	
27	HIToolbox	HIToolbox@0x302bf	
28	HIToolbox	HIToolbox@0x30011	
29	HIToolbox	HIToolbox@0x2ff4c	
30	AppKit	AppKit@0x40d7c	
31	AppKit	AppKit@0x4062f	
32	thunderbird-bin	nsAppShell::ProcessNextNativeEvent	widget/src/cocoa/
33	thunderbird-bin	nsBaseAppShell::DoProcessNextNativeEvent	widget/src/xpwidgets/nsBaseAppShell.cpp:151
34	thunderbird-bin	nsBaseAppShell::OnProcessNextEvent	widget/src/xpwidgets/nsBaseAppShell.cpp:278
35	thunderbird-bin	nsAppShell::OnProcessNextEvent	widget/src/cocoa/
36	libxpcom_core.dylib	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:497
37	libxpcom_core.dylib	NS_ProcessPendingEvents_P	nsThreadUtils.cpp:180
38	thunderbird-bin	nsBaseAppShell::NativeEventCallback	widget/src/xpwidgets/nsBaseAppShell.cpp:121
39	thunderbird-bin	nsAppShell::ProcessGeckoEvents	widget/src/cocoa/
40	CoreFoundation	CoreFoundation@0x735f4	
41	CoreFoundation	CoreFoundation@0x73cd7	
42	HIToolbox	HIToolbox@0x302bf	
43	HIToolbox	HIToolbox@0x300d8	
44	HIToolbox	HIToolbox@0x2ff4c	
45	AppKit	AppKit@0x40d7c	
46	AppKit	AppKit@0x4062f	
47	AppKit	AppKit@0x3966a	
48	thunderbird-bin	nsAppShell::Run	widget/src/cocoa/
49	thunderbird-bin	nsAppStartup::Run	toolkit/components/startup/src/nsAppStartup.cpp:192
50	thunderbird-bin	XRE_main	toolkit/xre/nsAppRunner.cpp:3279
51	thunderbird-bin	main	nsMailApp.cpp:103
For Thunderbird, changes to socorro processing have morphed crashes to 
 _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)
~5% of Thunderbird 3.0 crashes, making this #5 crasher (when excluding #1 enigmail)

FF signature is unchanged
Keywords: topcrash
Summary: crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] → crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] or [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]
Keywords: qawanted
gc issue?  or is upper stack totally bogus and the problem really in thunderbird code?

for example bp-0f09a857-dbc9-4565-bab3-7bca52100104 (has no extensions)
0	ntdll.dll	KiFastSystemCallRet	
1	ntdll.dll	NtWaitForSingleObject	
2	kernel32.dll	WaitForSingleObjectEx	
3	kernel32.dll	WaitForSingleObject	
4	thunderbird.exe	google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread	toolkit/crashreporter/google-breakpad/src/client/windows/handler/
5	thunderbird.exe	google_breakpad::ExceptionHandler::HandlePureVirtualCall	toolkit/crashreporter/google-breakpad/src/client/windows/handler/
6	mozcrt19.dll	_purecall	objdir-tb/mozilla/memory/jemalloc/src/purevirt.c:47
7	thunderbird.exe	nsXPCWrappedJS::QueryInterface	js/src/xpconnect/src/xpcwrappedjs.cpp:173
8	xpcom_core.dll	canonicalize	xpcom/base/nsCycleCollector.cpp:1161
9	xpcom_core.dll	GCGraphBuilder::NoteXPCOMChild	xpcom/base/nsCycleCollector.cpp:1447
10	thunderbird.exe	nsXPCWrappedJS::cycleCollection::Traverse	js/src/xpconnect/src/xpcwrappedjs.cpp:74
11	xpcom_core.dll	GCGraphBuilder::Traverse	xpcom/base/nsCycleCollector.cpp:1372
12	xpcom_core.dll	nsCycleCollector::MarkRoots	xpcom/base/nsCycleCollector.cpp:1571
13	xpcom_core.dll	nsCycleCollector::BeginCollection	xpcom/base/nsCycleCollector.cpp:2504
14	thunderbird.exe	XPCCycleCollectGCCallback	js/src/xpconnect/src/nsXPConnect.cpp:390
15	js3250.dll	js_GC	js/src/jsgc.cpp:3500
16	js3250.dll	JS_GC	js/src/jsapi.cpp:2458
17	thunderbird.exe	nsXPConnect::Collect	js/src/xpconnect/src/nsXPConnect.cpp:477
18	xpcom_core.dll	nsCycleCollector::Collect	xpcom/base/nsCycleCollector.cpp:2386
19	xpcom_core.dll	nsCycleCollector_collect	xpcom/base/nsCycleCollector.cpp:3045
20	thunderbird.exe	nsJSContext::CC	dom/src/base/nsJSEnvironment.cpp:3512
21	thunderbird.exe	nsJSContext::MaybeCC	dom/src/base/nsJSEnvironment.cpp:3580
22	thunderbird.exe	nsJSContext::CCIfUserInactive	dom/src/base/nsJSEnvironment.cpp:3597
23	thunderbird.exe	GCTimerFired	dom/src/base/nsJSEnvironment.cpp:3620
24	xpcom_core.dll	nsTimerImpl::Fire	xpcom/threads/nsTimerImpl.cpp:420
25	xpcom_core.dll	nsTimerEvent::Run	xpcom/threads/nsTimerImpl.cpp:512
26	xpcom_core.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:521
27	xpcom_core.dll	NS_ProcessNextEvent_P	objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:236
28	thunderbird.exe	nsXULWindow::ShowModal	xpfe/appshell/src/nsXULWindow.cpp:415
29	thunderbird.exe	nsContentTreeOwner::ShowAsModal	xpfe/appshell/src/nsContentTreeOwner.cpp:528
blocking1.9.1: --- → ?
wayne: this basically means that an object was in a certain state of dead and its pointers were swapped for _purecall, that object should have been unreachable (since it obviously died...), however it obviously wasn't properly unreachable because the cyclecollector hit it. The stack is valid.

The reason you see frames 0..5 is because of how _purecall works, in general a crash is an access violation, but for _purecalls, you don't quite crash, you're dead in a way that would normally mean calling into really random confusing bad states, _purecall helps out developers by explaining "you're here because of purecall", and classically it does this by tossing up a genuine dialog saying "whoops, someone made a purecall", since that dialog isn't quite the same thing as actually crashing (when you dismiss the dialog, the app kills itself), breakpad needs to have its own special code specifically for it, which is the explanation for how frames 6..4 are shaped. The actual thread responsible for doing the dump is another one, and in order to let the stack dumping work, the crashed thread has to block waiting (which explains frames 3..0).
Assignee: nobody → mrbkap
blocking1.9.1: ? → ---
blocking2.0: --- → ?
mrbkap, any theories on when you might be able to look at this?
So, this is going to be extremely hard to chase down. I don't know when I'm going to get a chance to really look at this. Sorry.
still steady at #5 crash for v3.0.4

not many crash comments, but all are about adding new accounts.
Tried to open new account.
tried to add an account checked with errors smtp and pop settings then after correcting it was impossible to re-check config so i canceled, then re-create account on check of config this time crash
Repeatable crash after installing and filling out the first email account. Cycles through detection of pop3 and smtp server information and then dies. Windows 7.

so pmed bp-cb61a41a-9b59-4605-bdfb-c7aa82100412 (joel)
Whiteboard: js_LookupPropertyWithFlags
Whiteboard: js_LookupPropertyWithFlags → [tbird crash]
I've just posted on the extension development forum because I hit the same crash with my add-on. I'm not sure how related the issues are but there appears to be a common use of nsIOutputStreamCallback.onOutputStreamReady(). Even if it turns out that I'm just doing something stupid in my extension, I thought it might help narrow down what's causing these crashes.
blocking 1.9.3 final+
blocking2.0: ? → final+
looks like this has reduced in volume (at least for firefox).  has it done the same for tbird?

date     tl crashes at, count build, count build, ...
20101001 14  10 3.6.102010091412, 
	     1 4.0b52010083108, 1 3.6.82010072215, 
	     1 3.6.32010040108, 1 3.0.192010031422, 
20101002 10  8 3.6.102010091412, 
	     1 4.0b32010080519, 1 3.6b22009110818, 
20101003 12  10 3.6.102010091412, 
	     1 4.0b12010063014, 1 3.6.82010072215, 
20101004 8  4 3.6.102010091412, 
	     1 4.0b62010091408, 1 3.6b42009112421, 
	     1 3.6.82010072215, 1 3.5.132010091413, 
20101005 9  6 3.6.102010091412, 
	     1 3.6.32010040108, 1 3.6.112010100108, 
	     1 3.5.132010091413, 
20101006 7  6 3.6.102010091412, 
	     1 3.5.132010091413, 
20101007 7  4 3.6.102010091412, 
	     1 3.6.82010072215, 1 3.6.32010040108, 
	     1 3.0.32008092417, 
20101008 7  5 3.6.102010091412, 
	     1 3.7a32010031509, 1 3.5.132010091413, 
20101009 8  5 3.6.102010091412, 
	     1 4.0b62010091408, 1 3.6.112010100108, 
	     1 3.5b42009042320, 
20101010 5  3 3.6.102010091412, 
	     1 4.0b52010083108, 1 3.6.82010072215,
Keywords: topcrash
chris, For tbird...

nsXPCWrappedJS::QueryInterface(nsID const&, void**) never existed in great quantity in thunderbird - roughly less than 1-2 crashes per month per version. So there's no way to assign numerical significance to any changes in crash rate up or down in the past 6 months. 

_purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**) is a different beast -  non-existent in v3.1.anything**. but big numbers (2,000+ plus crashes per month per the most current v3.0 release of the month) until we turned on the MU major update to v3.1. **however, there are  rare crashes on trunk such as
firefox 4.0 b5/6 volume regress part of this bug has been spun off to bug 607867
I see 0 crashes with the signature "nsXPCWrappedJS::QueryInterface(nsID const&, void**)" since 11/4, so not blocking on this. Bug 607867 seems to cover the other signature, so I'm doubtful there's even a reason to keep this bug open any more...
blocking2.0: final+ → -
jst, thanks for checking and updating this. I agree this can be closed

thunderbird _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)
no crashes in 3.1, and no trunk crashes since build 20100915033551 bp-2654295c-6ec4-4b41-9bbd-e53012100921
... so this is "gone" 

thunderbird nsXPCWrappedJS::QueryInterface(nsID const&,
bp-d8ef4e06-1f90-496d-9c40-a559e2101206 v3.1.6
bp-b1c7d3fe-3d62-4d4d-bec8-13ea02101202 v3.1.6
bp-0840ec4f-6617-4078-8300-94b302101118 v3.1.6
... is all I find in the last month, all different stacks and none match this bug

still a topcrash for v3.0.x. but for 3.1.x and trunk this is gone

=> WFM
Closed: 11 years ago
Resolution: --- → WORKSFORME
This crash is happening in 4.0 and 4.0.1, reopening.
Resolution: WORKSFORME → ---
Crash Signature: [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]
I don't see any crashes like this in the top 300 on Firefox 31 beta.
Crash Signature: [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)] → [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]
Closed: 11 years ago7 years ago
Resolution: --- → WORKSFORME
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.