819337 - Firefox 20 crash in nsXPConnect::GetXPConnect

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[Scoobidiver (away)]

It started spiking in 20.0a1/20121206 and is currently #3 top crasher in today's build. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1942b4d64dc8&tochange=3c81e1c0d252

Stack traces are various:
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXPConnect::GetXPConnect 	js/xpconnect/src/nsXPConnect.cpp:140
1 	xul.dll 	nsXPConnect::Push 	js/xpconnect/src/nsXPConnect.cpp:2158
2 	xul.dll 	nsCxPusher::DoPush 	content/base/src/nsContentUtils.cpp:3052
3 	xul.dll 	nsImageFrame::DestroyFrom 	layout/generic/nsImageFrame.cpp:205
4 	xul.dll 	nsBlockFrame::DoRemoveFrame 	layout/generic/nsBlockFrame.cpp:5409
5 	xul.dll 	nsBlockFrame::RemoveFrame 	layout/generic/nsBlockFrame.cpp:4968
6 	xul.dll 	nsFrameManager::RemoveFrame 	layout/base/nsFrameManager.cpp:499
...

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXPConnect::GetXPConnect 	js/xpconnect/src/nsXPConnect.cpp:140
1 	xul.dll 	xpc::XrayWrapper<js::CrossCompartmentWrapper,xpc::XPCWrappedNativeXrayTraits>::g 	js/xpconnect/wrappers/XrayWrapper.cpp:1347
2 	mozjs.dll 	js::BaseProxyHandler::get 	js/src/jsproxy.cpp:89
3 	xul.dll 	xpc::XrayWrapper<js::CrossCompartmentWrapper,xpc::XPCWrappedNativeXrayTraits>::g 	js/xpconnect/wrappers/XrayWrapper.cpp:1599
4 	mozjs.dll 	proxy_GetGeneric 	js/src/jsproxy.cpp:2651
5 	mozjs.dll 	JSObject::getGeneric 	js/src/jsobjinlines.h:169
6 	mozjs.dll 	js::GetPropertyOperation 	js/src/jsinterpinlines.h:286
7 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2200
...

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXPConnect::GetXPConnect 	js/xpconnect/src/nsXPConnect.cpp:140
1 	xul.dll 	XPCConvert::NativeInterface2JSObject 	js/xpconnect/src/XPCConvert.cpp:832
2 	xul.dll 	xpc_qsXPCOMObjectToJsval 	js/xpconnect/src/XPCQuickStubs.cpp:977
3 	xul.dll 	nsIDOMNodeSelector_QuerySelectorAll 	obj-firefox/js/xpconnect/src/dom_quickstubs.cpp:1975
4 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:369
5 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2321
6 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:318
7 	mozjs.dll 	JS_WrapObject 	js/src/jsapi.cpp:1522
8 	xul.dll 	XPC_WN_OuterObject 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:778
9 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:417
...

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXPConnect::GetXPConnect 	js/xpconnect/src/nsXPConnect.cpp:140
1 	xul.dll 	XPC_WN_CallMethod 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1488
2 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:369
3 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2321
...

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXPConnect::GetXPConnect 	js/xpconnect/src/nsXPConnect.cpp:140
1 	xul.dll 	XPCJSRuntime::Get 	js/xpconnect/src/xpcprivate.h:667
2 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/xpconnect/src/XPCWrappedJSClass.cpp:1470
3 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/xpconnect/src/XPCWrappedJS.cpp:580
4 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:85
...

and so on.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsXPConnect%3A%3AGetXPConnect%28%29

Comment 1

[Andrew McCreight [:mccr8]]

Line 140 is a MOZ_CRASH() because we're trying to get XPConnect off the main thread. However, of the ten or so I looked at, almost all were on thread 0, which seems like it should be the main thread. The stacks were mostly truncated, but for those that weren't, they did look like the actual main thread. So I'm not sure what is going on.

Comment 2

[Scoobidiver (away)]

Crashes have almost completely stopped since 20.0a1/20121208, maybe fixed by the patch of bug 818962.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Was this crash correlated with the bad AMD Radeon drivers? Sorry, I don't know how to get crash-stats to tell me, but the reports I've pulled all look like it.

The crash I'm looking at in the debugger on juanb's machine is in GetXPConnect(), but I'm not sure if it's the same as in these crash reports; the dumps look a little different. In the crash I'm seeing, the EBP register is 0x2B when it should be a valid frame pointer, and we're crashing during the function epilogue after setting ESP to 0x2B and then trying to pop the saved EBP.

How EBP got into this state is the question. EBP is sometimes temporarily used as a general-purpose register so it's possible that happened and we jumped into the middle of GetXPConnect from some other function --- I can't tell since I don't have a stack for this crash, not having a valid stack pointer.

Comment 4

[Scoobidiver (away)]

(In reply to Scoobidiver from comment #2)
> Crashes have almost completely stopped since 20.0a1/20121208, maybe fixed by
> the patch of bug 818962.
Let's close it.