If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Crash in CheckCanChangeActiveContext when open devtools + Quantum DOM scheduler enabled

NEW
Unassigned

Status

()

Core
DOM: Content Processes
--
critical
20 days ago
15 days ago

People

(Reporter: kanru, Unassigned, NeedInfo)

Tracking

({crash})

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

20 days ago
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.
Duplicate of this bug: 1395546
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?
Flags: needinfo?(bhackett1024)
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.
Flags: needinfo?(bhackett1024) → needinfo?(wmccloskey)
You need to log in before you can comment on or make changes to this bug.