This bug was filed from the Socorro interface and is report bp-7fc7d4ac-f600-4da1-b69c-bc2982170318. ============================================================= Crashing Thread (0) Frame Module Signature Source 0 xul.dll js::DispatchTyped<DoCallbackFunctor<JS::Value>, JS::CallbackTracer*&, char const*&>(DoCallbackFunctor<JS::Value>, JS::Value const&, JS::CallbackTracer*&, char const*&) obj-firefox/dist/include/js/Value.h:1439 1 xul.dll js::TraceManuallyBarrieredEdge<JS::Value>(JSTracer*, JS::Value*, char const*) js/src/gc/Marking.cpp:468 2 xul.dll JSObject::traceChildren(JSTracer*) js/src/jsobj.cpp:3883 3 xul.dll JS::DispatchTraceKindTyped<UnmarkGrayCellRecursivelyFunctor>(UnmarkGrayCellRecursivelyFunctor, void*, JS::TraceKind) obj-firefox/dist/include/js/TraceKind.h:205 4 xul.dll JS::UnmarkGrayGCThingRecursively(JS::GCCellPtr) js/src/gc/Marking.cpp:3388 5 xul.dll nsMessageManagerScriptExecutor::MarkScopesForCC() dom/base/nsFrameMessageManager.cpp:1692 6 xul.dll nsInProcessTabChildGlobal::MarkForCC() dom/base/nsInProcessTabChildGlobal.cpp:121 7 xul.dll MarkChildMessageManagers dom/base/nsCCUncollectableMarker.cpp:137 8 xul.dll MarkChildMessageManagers dom/base/nsCCUncollectableMarker.cpp:121 9 xul.dll MarkChildMessageManagers dom/base/nsCCUncollectableMarker.cpp:121 10 xul.dll MarkMessageManagers dom/base/nsCCUncollectableMarker.cpp:168 11 xul.dll nsCCUncollectableMarker::Observe(nsISupports*, char const*, char16_t const*) dom/base/nsCCUncollectableMarker.cpp:457 12 xul.dll nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverList.cpp:112 13 xul.dll nsObserverService::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverService.cpp:281 14 xul.dll XPCJSContext::PrepareForForgetSkippable() js/xpconnect/src/XPCJSContext.cpp:709 15 xul.dll nsCycleCollector::ForgetSkippable(bool, bool) xpcom/base/nsCycleCollector.cpp:2859 16 xul.dll FireForgetSkippable dom/base/nsJSEnvironment.cpp:1251 17 xul.dll CCTimerFired dom/base/nsJSEnvironment.cpp:1828 18 xul.dll nsTimerImpl::Fire(int) xpcom/threads/nsTimerImpl.cpp:479 19 xul.dll nsTimerEvent::Run() xpcom/threads/TimerThread.cpp:297 20 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1264 21 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:389 22 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:124 23 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:231 24 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:211 25 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp:156 26 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp:263 27 xul.dll nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp:283 28 xul.dll XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp:4492 29 xul.dll XREMain::XRE_main(int, char** const, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:4670 30 xul.dll mozilla::BootstrapImpl::XRE_main(int, char** const, mozilla::BootstrapConfig const&) toolkit/xre/Bootstrap.cpp:45 31 firefox.exe NS_internal_main(int, char**, char**) browser/app/nsBrowserApp.cpp:307 32 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:115 33 firefox.exe __scrt_common_main_seh f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:253 34 kernel32.dll BaseThreadInitThunk 35 ntdll.dll RtlUserThreadStart Application Basics: Name: Firefox Version: 54.0a2 Build ID: 20170318004003 User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0

the signature is somewhat increasing in volume on the beta channel since the beginning of may: https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=beta&signature=js%3A%3ADispatchTyped%3CT%3E&date=%3E%3D2017-03-01T00%3A00%3A00.000Z#graphs

Hi Nathan, Can you help find someone to look at this issue?

Between Jason and Naveed being ni?'d, we ought to be able to find somebody. :)

Requesting tracking for this crash, as it does seem to be spiking.

Track 54+/55+ as the volume of crashes seems to be spiking.

Looking at the proto signatures, these seem like they are mostly in the GC (unlike the stack in comment 0). Here's a crash with the most common proto signature: bp-a2e73383-fde8-407d-8476-3e8cc0170518 This looks like a typical memory corruption GC crash so I'm not sure if we can do anything, but maybe Jon has some ideas.

Really, this should probably be duped over to bug 719114 and added as an additional signature, as I expect this is mostly a variation of [@ js::GCMarker::lazilyMarkChildren ] where we didn't inline DispatchTyped for some reason.

yeah, it also looks like the volume of js::GCMarker::lazilyMarkChildren was decreasing on the beta channel while js::DispatchTyped<T> spiked up...

Too late for 54 as we've built 54 RC. Mark 54 won't fix.

From discussion in the duplicate bug this doesn't sound actionable.