873589 - Firefox deadlocks if nsWindowMediatorListener tries to enumerate windows

Status: NEW

(Core :: Widget, defect, P3)

Description

[Jim Blandy :jimb]

It's easy to make the MutexAutoLock in nsWindowMediator::UnregisterWindow deadlock with the MutexAutoLock in nsWindowMediator::GetEnumerator.

- Open up two top-level windows.
- Evaluate the following in a chrome-privileged scratchpad:

  let l = {}
  l.onOpenWindow = l.onWindowTitleChange = () => {};
  l.onCloseWindow = (aWindow) => {
    Services.wm.getEnumerator("navigator:browser");
  };
  Services.wm.addListener(l);

Firefox becomes flustered and hangs, saying:

###!!! ERROR: Potential deadlock detected:
=== Cyclical dependency starts at
--- Mutex : nsWindowMediator.mListLock (currently acquired)
 calling context
  [stack trace unavailable]

=== Cycle completed at
--- Mutex : nsWindowMediator.mListLock (currently acquired)
 calling context
  [stack trace unavailable]

###!!! Deadlock may happen NOW!

###!!! ASSERTION: Potential deadlock detected:
Cyclical dependency starts at
Mutex : nsWindowMediator.mListLock (currently acquired)
Cycle completed at
Mutex : nsWindowMediator.mListLock (currently acquired)

###!!! Deadlock may happen NOW!

: 'Error', file /home/jimb/moz/dbg/obj-bug/xpcom/build/BlockingResourceBase.cpp, line 128



Is this list really even used by multiple threads at all? Could we remove the lock? (Is the mediator's enumerator and list management written carefully enough to permit this kind of re-entrant use at all?)

Comment 1

[Benjamin Smedberg]

I cannot imagine that it is actually threadsafe, but you should add some runtime aborts if you want to try removing the lock, so that failures show up both on tinderbox and in the wild.