628102 - Crash in xpc::AccessCheck::isChrome

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Carsten Book [:Tomcat]]

Crashreport - Firefox 4.0b9 Crash Report [@ xpc::AccessCheck::isChrome(JSCompartment*) ] - http://crash-stats.mozilla.com/report/list?signature=xpc::AccessCheck::isChrome%28JSCompartment*%29
 
Windows only crash

one comment mentioned something ( i think from webmail ovh.net and ssl connection)

trying to reproduce this crash


Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	xpc::AccessCheck::isChrome 	js/src/xpconnect/wrappers/AccessCheck.cpp:99
1 	xul.dll 	xpc::WrapperFactory::Rewrap 	js/src/xpconnect/wrappers/WrapperFactory.cpp:216
2 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:285
3 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:315
4 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:277
5 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:315
6 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:277
7 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:315
8 	mozjs.dll 	JS_WrapObject 	js/src/jsapi.cpp:1249
9 	xul.dll 	XPCConvert::NativeInterface2JSObject 	js/src/xpconnect/src/xpcconvert.cpp:1216
10 	xul.dll 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcconvert.cpp:494
11 	xul.dll 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcprivate.h:3202
12 	xul.dll 	XPC_WN_GetterSetter 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1643
13 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:700
14 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
15 	mozjs.dll 	js::JSProxyHandler::call 	js/src/jsproxy.cpp:248
16 	mozjs.dll 	JSCrossCompartmentWrapper::call 	js/src/jswrapper.cpp:616
17 	mozjs.dll 	js::JSProxy::call 	js/src/jsproxy.cpp:810
18 	mozjs.dll 	js::proxy_Call 	js/src/jsproxy.cpp:1062
19 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:693
20 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
21 	mozjs.dll 	js::ExternalGetOrSet 	js/src/jsinterp.cpp:898
22 	mozjs.dll 	js::JSProxyHandler::get 	js/src/jsproxy.cpp:131
23 	xul.dll 	xpc::XrayWrapper<JSCrossCompartmentWrapper,xpc::CrossCompartmentXray>::get 	js/src/xpconnect/wrappers/XrayWrapper.cpp:752
24 	mozjs.dll 	js::JSProxy::get 	js/src/jsproxy.cpp:778
25 	mozjs.dll 	js::proxy_GetProperty 	js/src/jsproxy.cpp:895
26 	mozjs.dll 	JSObject::getProperty 	js/src/jsobj.h:1189
27 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4220
28 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:657
29 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:737
30 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
31 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5009
32 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1700
33 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
34 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
35 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
36 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1114

Comment 1

[Andreas Gal :gal]

Looks like a NULL compartment.

Comment 2

[Andreas Gal :gal]

bent, could a worker compartment be involved in this stack? (that would explain the NULL principal)

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I don't think so... Any code running on the main thread has a normal DOM compartment.

Comment 4

[David Mandelin [:dmandelin]]

This looks low-volume now (there was a spike Jan 10).

Comment 6

[Scoobidiver (away)]

It is #4 top browser crasher on Mac OS X in 5.0.1 and #12 in 6.0.

Windows crash reports at:
http://crash-stats.mozilla.com/report/list?signature=xpc::AccessCheck::isChrome%28JSCompartment*%29
Mac and Linux crash reports at:
https://crash-stats.mozilla.com/report/list?signature=xpc%3A%3AAccessCheck%3A%3AisChrome

Comment 7

[Luke Wagner [:luke]]

Two interesting bits of data from the crashes:

While there is a lot of variation in who calls NativeInterface2JSObject, the top of the crash is always:
  JS_WrapObject -> wrap -> wrap -> WrapperFactory::Rewrap -> isChrome
In particular, there are always >= 2 wrap calls which means we are wrapping a prototype.

Second, the NULL compartment comes from cx->compartment (as in, the cx passed to JS_WrapObject).  Now, if cx->compartment was NULL on entry, I'm pretty sure we would have crashed when we did any number of cx->compartment member accesses getting to where we crash.  Thus, it would appear that cx->compartment is getting set to NULL in the process of wrapping.  Any idea how this could happen?

Comment 8

[Luke Wagner [:luke]]

Correction: sometimes there is only a single 'wrap' in the stack.

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: view-source

Also occurred on Fennec / android on nightly beta :
Mozilla/5.0 (Android; Linux armv7I; rv:7.0) Gecko/20110816 Firefox/7.0 Fennec/7.0
Device: Thunderbolt
OS: Android 2.2

Things I recall doing : opening all of the about: pages, restarting in danish, going to www.nytimes.com 

Note: nytimes.com has a video player for HTML5 delivery

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Forgot to mention I also installed the addon called "nightly tester tools"

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.