673835 - crash wrapping object returned from JS_NewArrayObject

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Josh Matthews [:jdm]]

This bug was filed from the Socorro interface and is 
report bp-cbb0a097-dbf9-4bc8-bca4-409c72110720 .
============================================================= 

This is puzzling. We create an array, then immediate try to wrap it, then we crash deferencing obj->getClass() in JSCompartment::wrap, address 0xdadadb26. No STR, unfortunately.

0 	libxul.so 	JSCompartment::wrap 	js/src/jscompartment.cpp:250
1 	libxul.so 	JS_WrapValue 	js/src/jsapi.cpp:1300
2 	libxul.so 	nsFrameMessageManager::ReceiveMessage 	content/base/src/nsFrameMessageManager.cpp:385
3 	libxul.so 	nsAsyncMessageToParent::Run 	content/base/src/nsInProcessTabChildGlobal.cpp:90
4 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:617
5 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
6 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
7 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:218
8 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:189
9 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:224
10 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3571

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Josh - Do we have reports of this from the field yet? In case we need to escalate the priority.

Comment 2

[Josh Matthews [:jdm]]

This is the only report I've seen in the field while trawling crash stats. We shouldn't be seeing it anywhere besides nightly and aurora, so unless it's a topcrash I don't expect to see many instances of it until it reaches a larger audience.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This is a pretty weird bug. The 0xdadadb26 address means that the object allocated in JS_NewArrayObject has been GCed by the time we wrap it. The getClass() op is returning 0xdadadada, which is what gets written to freshly swept objects.

The only possible GC point that I see between the array object allocation and the crash is when NULLABLE_OBJ_TO_INNER_OBJECT may be called (and I don't know what that does). But the array object is already explicitly rooted by then, and that code is pretty foolproof.

It's possible there's some sort of really bad thing happening with background sweeping in the GC. If this becomes a more common problem, we can try disabling background sweeping on ARM and see if that fixes it.

Comment 4

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

Crash volume for signature 'JSCompartment::wrap':
 - nightly (version 51): 5 crashes from 2016-08-01.
 - aurora  (version 50): 3 crashes from 2016-08-01.
 - beta    (version 49): 122 crashes from 2016-08-02.
 - release (version 48): 111 crashes from 2016-07-25.
 - esr     (version 45): 32 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       1       2       1
 - aurora        2       1       0
 - beta         36      46      12
 - release      36      31      19
 - esr           3       1       4

Affected platforms: Windows, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly #512
 - aurora            #479
 - beta    #354      #938
 - release #586      #449
 - esr     #1309

Comment 5

[Josh Matthews [:jdm]]

No STR, filed based on e10s-enabled Fennec from 6 years ago.