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

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

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.

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.

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

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