Mir server seems to spin at 100% and steals focus from everything until the server shutdown

I've not seen this but... the only active thread is deep in Mir code:

Thread 4 (Thread 0x7ffbca8b1700 (LWP 4472)):
#0 0x00007ffbd2ff65c3 in std::vector<std::shared_ptr<mir::scene::Session>, std::allocator<std::shared_ptr<mir::scene::Session> > >::begin (this=0x55bdec7b03a8) at /usr/include/c++/6/bits/stl_vector.h:558
#1 0x00007ffbd2ff60b6 in mir::scene::DefaultSessionContainer::successor_of (this=0x55bdec7b03a0, session=std::shared_ptr (count 3, weak 4) 0x7ffbb4000b30)
    at /home/bschaefer/src/trunk-pure-mir/src/server/scene/default_session_container.cpp:69
#2 0x00007ffbd3005492 in mir::scene::SessionManager::successor_of (this=0x55bdec7b11a0, session=std::shared_ptr (count 3, weak 4) 0x7ffbb4000b30) at /home/bschaefer/src/trunk-pure-mir/src/server/scene/session_manager.cpp:149
#3 0x00007ffbd30fa2e7 in mir::shell::AbstractShell::focus_next_session (this=0x55bdec7b1260) at /home/bschaefer/src/trunk-pure-mir/src/server/shell/abstract_shell.cpp:244

But I don't see any reason for this to be in an infinite loop. My only thought is that *if* this is an "invalid session" this *might* throw an exception and provoke odd behavior. Next time you see it could you set a breakpoint and step through this code?

I've got this while reproducing lp:1625846 (and running on mesa-drm, not on X11 and Mir-0.24, not a locally built trunk).

Although the stack traces are a bit different: all of the threads are in __lll_lock_wait(), pthread_cond_wait() __GI___pthread_mutex_lock(), or poll().

I'm also lacking Mir debug symbols, so I'm not sure how useful this is.

The system is looping in msh::AbstractShell::focus_next_session().

This can happen if two conditions apply:

1. All sessions have a null default_surface(); and,
2. focused_session is null.

That makes it a Mir bug.

The reason we've not seen it before is that we rarely have application sessions without surfaces. Unless we're testing with Xmir (but no X11 apps) and close the last native application.

Duplicate of bug 1592932 ?

> Duplicate of bug 1592932 ?

Very plausible, but I'm not sure how it can cause two Unity8 sessions.

Not immediately clear how to verify that the fix proposed in the linked branch address the problem as stated there. But if we could verify that, then maybe we should cherrypick for 0.24.1?

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.25.0

Fix committed to lp:mir/0.24 at revision 3641, scheduled for release in Mir 0.24.1

This bug was fixed in the package mir - 0.24.1+16.10.20160928-0ubuntu1

---------------
mir (0.24.1+16.10.20160928-0ubuntu1) yakkety; urgency=medium

  * New upstream release 0.24.1 (https://launchpad.net/mir/+milestone/0.24.1)
    - ABI summary:
      . All ABI numbers remain unchanged.
      . mircommon ABI at 6, but now including a symbol misplaced in 0.24.0
    - Bugs fixed:
      . mirserver ignored further keymap configuration changes after a keyboard
        is configured (LP: #1626435)
      . fix for libmircommon.so.6 ABI break: version stanza of
        mir::dispatch::ReadableFd* moved to newer version (LP: #1617865)
      . clang builds fail (again) (LP: #1609612)
      . Valgrind errors in NesterServer.* cause subsequent tests
        (ServerDisconnect, ServerStartup, UnresponsiveClient) to fail
        (LP: #1612012)
      . Break potentially infinite loop in search for next session to focus
        (LP: #1625401)

 -- Andreas Pokorny <email address hidden> Wed, 28 Sep 2016 12:09:49 +0000