Looking at the stack traces, it seems to generally happen on phones when the screen tries to turn on due to a proximity event from dbus/powerd.
The only reasonable explanation I can find is due to the fact that MultiThreadedCompositor::start/stop() are not locked. Instead they use atomic compare/exchange so are written assuming stop/start are called from the same thread. If stop and start are not called from the same thread under USC then it's possible we're trying to start the compositor while it's still stopping. And that might result in us waiting for incorrect CompositingFunctors. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1528384 Title: unity-system-compositor crashed with std::runtime_error in mir::compositor::CompositingFunctor::wait_until_started() from usc::MirScreen::set_screen_power_mode (mir_power_mode_on) To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1528384/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
