This bug was filed from the Socorro interface and is report bp-37b34a21-da38-4dee-af82-7c2940170830. ============================================================= STR: 1. Set about:config dom.ipc.scheduler = true dom.ipc.scheduler.chaoticScheduling = false dom.ipc.scheduler.preemption = false dom.ipc.scheduler.threadCount = 2 dom.ipc.scheduler.useMultipleQueues = true 2. Select a tab and open devtools Stack: CheckCanChangeActiveContext js/src/vm/Runtime.cpp:366 JSRuntime::setActiveContext js/src/vm/Runtime.cpp:373 mozilla::CooperativeThreadPool::CooperativeThread::Yield xpcom/threads/CooperativeThreadPool.cpp:259 mozilla::detail::SchedulerEventQueue::GetEvent xpcom/threads/Scheduler.cpp:278 nsThread::ProcessNextEvent(bool, bool*) ... nsFrameMessageManager::ReceiveMessage mozilla::dom::TabChild::RecvAsyncMessage mozilla::dom::PBrowserChild::OnMessageReceived The crashing thread is not main thread so I'm not sure why TabChild::RecvAsyncMessage appears in the stack.
This is the #6 Windows topcrash in Nightly 20170901220209. Bug 1395546 also has the same signature. bhackett, you modified this failing assertion: > MOZ_RELEASE_ASSERT(group->ownerContext().context() == nullptr) in bug 1341321. Any ideas?
The JS debugger is not compatible with cooperative multithreading (the debugger can create arbitrary links between different zone groups, so if there are multiple threads around then particular threads can't maintain exclusive access to the zone group they are operating on). There are a couple of callbacks which the JS engine invokes when only one cooperative thread should be operating at a time (specified by SetSingleThreadedExecutionCallbacks); the JS shell uses these but AFAICT from dxr the browser does not. If these callbacks are used to ensure that only a single thread is used when a debugger is running, then the yield which triggered this crash should not need to be performed.