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

[Brandon Schaefer]

Start a Mir server (doesn't have to be miral-shell, but we'll use that example) with gnome-terminal:

$ miral-shell --startup gnome-terminal

In the terminal start and detach Xmir:

$ Xmir -rootless :1&

Close the terminal.

When I do hit this, unable to do anything key focus wise. (I can open a terminal ctrl+alt+t but i cant type into, mouse events work fine)

[Alan Griffiths (alan-griffiths)]

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?

[Alan Griffiths (alan-griffiths)]

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.

[Alan Griffiths (alan-griffiths)]

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.

[Alan Griffiths (alan-griffiths)]

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.

[Daniel van Vugt (vanvugt)]

Duplicate of bug 1592932 ?

[Alan Griffiths (alan-griffiths)]

> 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?

[Mir CI Bot (mir-ci-bot)]

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

[Daniel van Vugt (vanvugt)]

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

[Launchpad Janitor (janitor)]

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