765404 - crash in nsNodeSH::PreCreate

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[(mostly gone) XtC4UaLL [:xtc4uall]]

This bug was filed from the Socorro interface and is 
report bp-baef3494-a668-4c13-aba8-15b422120615 .
============================================================= 

Got this during Update of yesterday's Nightly to today's one in the Shutdown Process.


Frame 	Module 	Signature 	Source
0 	xul.dll 	nsNodeSH::PreCreate 	dom/base/nsDOMClassInfo.cpp:7907
1 	xul.dll 	XPCCallContext::XPCCallContext 	js/xpconnect/src/XPCCallContext.cpp:33
2 	xul.dll 	xpc::WrapperFactory::PrepareForWrapping 	js/xpconnect/wrappers/WrapperFactory.cpp:180
3 	mozglue.dll 	je_malloc 	memory/mozjemalloc/jemalloc.c:6293
4 	xul.dll 	JSObject::getGeneric 	js/src/jsobjinlines.h:162
5 	xul.dll 	js::DirectWrapper::get 	js/src/jswrapper.cpp:183
6 	xul.dll 	Enumerate 	js/src/jsiter.cpp:185
7 	xul.dll 	proxy_GetGeneric 	js/src/jsproxy.cpp:1308
8 	xul.dll 	JSContext::malloc_ 	js/src/jscntxt.h:1249
9 	xul.dll 	js::RunScript 	js/src/jsinterp.cpp:264
10 	xul.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:176
11 	xul.dll 	js::Invoke 	js/src/jsinterp.cpp:354
12 	xul.dll 	proxy_GetGeneric 	js/src/jsproxy.cpp:1307
13 	xul.dll 	js::CrossCompartmentWrapper::call 	js/src/jswrapper.cpp:656
14 	xul.dll 	JSObject::getGeneric 	js/src/jsobjinlines.h:177
15 	xul.dll 	proxy_Call 	js/src/jsproxy.cpp:1651
16 	xul.dll 	js::GetPropertyGenericMaybeCallXML 	js/src/jsinterpinlines.h:164
17 	xul.dll 	js::GetPropertyOperation 	js/src/jsinterpinlines.h:227
18 	xul.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:304
19 	xul.dll 	js::Interpret 	js/src/jsinterp.cpp:2331
20 	xul.dll 	nsScriptSecurityManager::CheckXPCPermissions 	caps/src/nsScriptSecurityManager.cpp:2919
21 	xul.dll 	JSObject::getGeneric 	js/src/jsobjinlines.h:162
22 	xul.dll 	AutoScriptEvaluate::~AutoScriptEvaluate 	js/xpconnect/src/XPCWrappedJSClass.cpp:79
23 	xul.dll 	js::EmptyShape::getInitialShape 	js/src/jsscope.cpp:1291
24 	xul.dll 	nsXPCWrappedJSClass::DelegatedQueryInterface 	js/xpconnect/src/XPCWrappedJSClass.cpp:751
25 	xul.dll 	js::EmptyShape::getInitialShape 	js/src/jsscope.cpp:1291
26 	xul.dll 	js::detail::HashTable<js::InitialShapeEntry const,js::HashSet<js::InitialShapeEn 	obj-firefox/dist/include/js/HashTable.h:791
27 	xul.dll 	js::EmptyShape::getInitialShape 	js/src/jsscope.cpp:1311
28 	xul.dll 	js::detail::HashTable<js::InitialShapeEntry const,js::HashSet<js::InitialShapeEn 	obj-firefox/dist/include/js/HashTable.h:791
29 	xul.dll 	js::EmptyShape::getInitialShape 	js/src/jsscope.cpp:1311
30 	xul.dll 	js::EmptyShape::getInitialShape 	js/src/jsscope.cpp:1311
31 	xul.dll 	js::detail::HashTable<js::InitialShapeEntry const,js::HashSet<js::InitialShapeEn 	obj-firefox/dist/include/js/HashTable.h:791
32 	xul.dll 	js::EmptyShape::getInitialShape 	js/src/jsscope.cpp:1311

Per Crashstats http://bit.ly/NEjjKH this Signature is reported across several past and recent Versions.

Comment 1

[Scoobidiver (away)]

It's #9 top browser crasher in 16.0a2.
There's no obvious correlation.

Comment 2

[Alex Keybl [:akeybl]]

Top crasher in 16, but present in previous versions as well. No other comments in the crash reports.

Unclear how to move forward here at this point except to see if this rings a bell. Including some DOM folks to see if this rings a bell.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So some notes:

1)  That stack linked from comment 0 is a null deref.
2)  It's claimed to be on this line:

  7906 nsresult rv = WrapNative(cx, globalObj, scope, false, &v,
  7907                          getter_AddRefs(holder)); 

    while wrapping the GetScopeObject() of the doc, which is known to be non-null there.
    So what's null?

3)  The stack does not make that much sense to me, honestly.  JSCompartment::wrap should
    not be calling js::RunScript, and JSContext::malloc_ should so not be calling
    proxy_GetGeneric.

Comment 4

[Scoobidiver (away)]

(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #3)
> 3)  The stack does not make that much sense to me, honestly.
It's a 64-bit stack trace.

A 32-bit stack trace looks like:
0 	xul.dll 	nsNodeSH::PreCreate 	dom/base/nsDOMClassInfo.cpp:7898
1 	xul.dll 	xpc::WrapperFactory::PrepareForWrapping 	js/xpconnect/wrappers/WrapperFactory.cpp:187
2 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:193
3 	mozjs.dll 	js::CrossCompartmentWrapper::get 	js/src/jswrapper.cpp:567
4 	mozjs.dll 	proxy_GetGeneric 	js/src/jsproxy.cpp:1319
5 	mozjs.dll 	js::GetPropertyOperation 	js/src/jsinterpinlines.h:266
6 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2338
7 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:355
8 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:387
9 	mozjs.dll 	js::CrossCompartmentWrapper::call 	js/src/jswrapper.cpp:689
10 	mozjs.dll 	proxy_Call 	js/src/jsproxy.cpp:1666
11 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:337
12 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2442
13 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:355
14 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:387
15 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5568
16 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/xpconnect/src/XPCWrappedJSClass.cpp:1436
17 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/xpconnect/src/XPCWrappedJS.cpp:580
18 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:85
19 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:112
20 	xul.dll 	nsObserverList::NotifyObservers 	xpcom/ds/nsObserverList.cpp:99

Comment 5

[Boris Zbarsky [:bzbarsky]]

That's much more plausible, yes.  ;)

Looking at an example like that (https://crash-stats.mozilla.com/report/index/31f833e6-ac4d-49a0-8286-208502120728 e.g.), the actual crash location is still a null deref in the place I mention in comment 3.  I wonder what gives....

Comment 6

[Johnny Stenback (:jst)]

I wonder if this code is somehow running when nsDOMClassInfo::XPConnect() return null?

Comment 7

[Alex Keybl [:akeybl]]

We'll leave this tracked till after our first beta, but it looks like this signature has really dropped off on Aurora 16.

Comment 8

[Johnny Stenback (:jst)]

Bobby, could you spend some time investigating this a bit further?

Comment 9

[Bobby Holley (:bholley)]

(In reply to Johnny Stenback (:jst, [e-mail]) from comment #6)
> I wonder if this code is somehow running when nsDOMClassInfo::XPConnect()
> return null?

Possibly. Assuming we buy Boris' analysis in comment 5, the crash happens in the call to WrapNative, which is actually inline, and contains another inline call to xpc_FastGetCachedWrapper.

So the crash is probably either in xpc_FastGetCachedWrapper or in nsDOMClassInfo::XPConnect(). Neither seems particularly likely.

Let's try to get some STR here.

Comment 10

[Alex Keybl [:akeybl]]

(In reply to Johnny Stenback (:jst, [e-mail]) from comment #8)
> Bobby, could you spend some time investigating this a bit further?

Actually, looking at crash-stats, this doesn't appear to be a top crasher any more in 16.0 beta. Sorry for the churn on this one.

Comment 11

[Bobby Holley (:bholley)]

(In reply to Alex Keybl [:akeybl] from comment #10)
> (In reply to Johnny Stenback (:jst, [e-mail]) from comment #8)
> > Bobby, could you spend some time investigating this a bit further?
> 
> Actually, looking at crash-stats, this doesn't appear to be a top crasher
> any more in 16.0 beta. Sorry for the churn on this one.

Ok, dropping this bug.

Comment 12

[Josh Matthews [:jdm]]

Point of interest: I have seen crashes during shutdown with storage callbacks running and calling into code that tries to use XPConnect after it has been shut down (ie. null sXPConnect pointer). Similar things could be happening here.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.