touch-packages team mailing list archive

[Daniel van Vugt <daniel.van.vugt@xxxxxxxxxxxxx>]

** Also affects: mir (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: mir (Ubuntu)
   Importance: Undecided => High

** Changed in: mir (Ubuntu)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mir in Ubuntu.
https://bugs.launchpad.net/bugs/1340669

Title:
  Intermittent deadlock when swithcing to session with custom display
  configuration while closing other session

Status in Mir:
  Fix Committed
Status in Mir 0.4 series:
  Won't Fix
Status in “mir” package in Ubuntu:
  Triaged

Bug description:
  If when closing a session we change focus to another session that has
  a custom display configuration, we may hit a deadlock.

  This can been seen occasionally as a hang when logging out of an X
  session under XMir. It currently only affects XMir because it is the
  only production client that applies custom display configurations.

  Here is how it happens:

  [IPC thread]

  ~SessionMediator
  SessionManager::close_session()
  SessionManager::set_focus_to_locked(next session)
  BroadcastingSessionEventSink::handle_focus_change()
  MediatingDisplayChanger handles the focus change event and enqueues a display reconfiguration action into AsioMainLoop

  From this point we have two interesting execution threads:

  [IPC thread continues]

  ~ApplicationSession
  ...
  mir::scene::Observers::surface_removed() *** Acquires READ lock on surface observer [1]
  ...
  AsioMainLoop::unregister_fd_handler *** Enqueues an action into AsioMainLoop and waits for it to complete

  [MainLoop thread]

  Executes display reconfiguration action:
  MultiThreadedCompositor::stop()
  mir::scene::Observers::remove() ** Acquires WRITE lock on observer [2]

  If the IPC thread calls the surface_removed() observer before the
  display reconfiguration action is executed, then the MainLoop thread
  at [2] ends up waiting for a WRITE lock, but can't get it because a
  READ lock has been acquired at [1]. At the same time, the IPC thread
  is blocked waiting for unregister_fd_handler() to return, but it
  doesn't return because the unregistration action has been enqueued
  after the display reconfiguration handler which is now blocked at [2].

To manage notifications about this bug go to:
https://bugs.launchpad.net/mir/+bug/1340669/+subscriptions