Xmir disconnects and reconnects to Mir when the X client count reaches zero

[Christopher Townsend]

Xmir reconnects to Mir when the final client drops its connection to Xmir, either through XCloseDisplay, or by normal program termination. This affects xprop and GTK applications (they temporarily open a connection to the X server to obtain the value of the AT_SPI_BUS property on the root window).

This is what is printed in application's upstart log:

(EE)
Fatal server error:
(EE) Failed to connect to Mir: Failed to process connect response: /build/mir-3eDTxk/mir-0.14.0+15.10.20150723.1/src/client/probing_client_platform_factory.cpp(37): Throw in function virtual std::shared_ptr<mir::client::ClientPlatform> mir::client::ProbingClientPlatformFactory::create_client_platform(mir::client::ClientContext*)
Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
std::exception::what: No appropriate client platform module found

(EE)

[Christopher Townsend (townsend)]

I'm also adding Mir to this since the error kind of implicates it.

[William Hua (attente)]

GTK apps are breaking this because at-spi2-core is calling XCloseDisplay, not because of XGetWindowProperty.

I tried commenting (https://git.gnome.org/browse/at-spi2-core/tree/atspi/atspi-misc.c#n1456, XGetWindowProperty call) and this bug still occurred. Then I tried commenting (https://git.gnome.org/browse/at-spi2-core/tree/atspi/atspi-misc.c#n1462, XCloseDisplay call) and it allows GTK apps to run without crashing XMir.

Aside, to run GTK apps under XMir, pass the display name as a command line argument (--display :1) instead of setting DISPLAY/AT_SPI_DISPLAY.

[Christopher Townsend (townsend)]

I also ran xprop in gdb to see what may be causing the Xmir window to clsoe and just the simple exit(0) at the end of xprop.c causes it to close.

Based on the call to XCloseDisplay() and xprop exiting causing Xmir to close, I'm wondering if Xmir is being too aggressive on cleaning up when the application is done with DISPLAY???? Need some expert advice here:)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christopher Townsend (townsend)]

I'm not sure if Xmir crashes. I ran xprop w/ gdb and it just seems Xmir exits when the client closes the display. I also don't get any crash file nor any evidence of a core dump.

[William Hua (attente)]

Ok, it might not be a crash per se, but it's definitely still printing fatal server error in the logs.

[Robert Ancell (robert-ancell)]

What version of XMir? I'm not getting any crashing here.

[William Hua (attente)]

This was with version 2:1.17.2-1ubuntu3. It might not be an actual crash, but Xmir is terminating with that exception in the logs.

[Daniel van Vugt (vanvugt)]

That error looks like one of the cryptic messages you'll get if you haven't installed drivers for Mir yet. They're not automatically installed unless you have a phone image, or have installed the full desktop-next stack. Reasons....

Try this:
   sudo apt-get install mir-graphics-drivers-desktop
or
   sudo apt-get install mir-graphics-drivers-android

[William Hua (attente)]

I have version 0.14.0+15.10.20150723.1-0ubuntu1 of mir-graphics-drivers-desktop installed.

[Christopher Townsend (townsend)]

Most definitely not the lack of the graphics drivers as I have those installed on my machine and have a working Unity 8 desktop session.

Another data point is that this doesn't occur when running against mir_demo_server, but only when running in a Unity 8 desktop session. I start an Xmir instance using a desktop file like the following:

$cat ~/.local/share/applications/xmir-debug.desktop
[Desktop Entry]
Version=1.0
Name=XMir Debug
Exec=Xmir :1
Type=Application
StartupNotify=true
X-Ubuntu-Touch=true

Then from an ssh session, I do something like:
$ DISPLAY=:1 xprop -root

I get the following output:
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""

But after the command is finished, the Xmir window goes away and the error message I put in the description is printed in ~/.cache/upstart/application-legacy-xmir-debug-blah.log.

The test program that William attached to this bug also produces the same behavior while in a Unity 8 desktop session.

I hope this helps. Also, considering it doesn't occur when running with mir_demo_server, it's probably not a Mir/Xmir issue, but I'm really not sure whose problem it is, but it needs fixing:)

[Robert Ancell (robert-ancell)]

The trigger is the X server resetting - this occurs when the last X client disconnects. This causes the root window to be destroyed and re-created. Thus the Mir surface is destroyed and then (attempted to be) recreated.

This occurs when running XMir inside a Unity 8 session, other cases that were tested were:
 - Running XMir inside mir_demo_server (works fine)
 - Running Unity 8 directly inside mir_demo_server (works fine)

In the normal use case the X server doesn't reset until you have completed using it - the window manager is constantly connected so the reset does not occur. For this reason this bug is not critical but worth investigating when we have the time.

[Daniel van Vugt (vanvugt)]

I wonder if this is another case of Mir choosing the wrong version of the right driver (bug 1488500). Can you please list all mir debs you have installed?

[William Hua (attente)]

These are the packages that I can replicate the bug with:

libmirprotobuf1:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmirserver33:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmirplatform9:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmircommon-dev:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmirplatform-dev:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmirserver-dev:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mirtest-dev:
  Installed: (none)
--
libmirclient9:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmirclient-dev:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmirclient-debug-extension1:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmirclient-debug-extension-dev:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mir-demos:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mir-utils:
  Installed: (none)
--
mir-doc:
  Installed: (none)
--
mir-test-tools:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
libmircommon5:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mir-platform-graphics-mesa-x4:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mir-platform-graphics-mesa-kms4:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mir-platform-graphics-android4:
  Installed: (none)
--
mir-client-platform-mesa3:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mir-client-platform-mesa-dev:
  Installed: (none)
--
mir-client-platform-android3:
  Installed: (none)
--
mir-graphics-drivers-desktop:
  Installed: 0.15.0+15.10.20150818-0ubuntu1
--
mir-graphics-drivers-android:
  Installed: (none)
--
python3-mir-perf-framework:
  Installed: (none)

[William Hua (attente)]

The bug still happens with the packages in Wily proposed:

libmirprotobuf1:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmirserver33:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmirplatform9:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmircommon-dev:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmirplatform-dev:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmirserver-dev:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mirtest-dev:
  Installed: (none)
--
libmirclient9:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmirclient-dev:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmirclient-debug-extension1:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmirclient-debug-extension-dev:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mir-demos:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mir-utils:
  Installed: (none)
--
mir-doc:
  Installed: (none)
--
mir-test-tools:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
libmircommon5:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mir-platform-graphics-mesa-x4:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mir-platform-graphics-mesa-kms4:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mir-platform-graphics-android4:
  Installed: (none)
--
mir-client-platform-mesa3:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mir-client-platform-mesa-dev:
  Installed: (none)
--
mir-client-platform-android3:
  Installed: (none)
--
mir-graphics-drivers-desktop:
  Installed: 0.15.1+15.10.20150825-0ubuntu1
--
mir-graphics-drivers-android:
  Installed: (none)
--
python3-mir-perf-framework:
  Installed: (none)

[Daniel van Vugt (vanvugt)]

For me I found much improved stability on client disconnection after this fix:

https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=9287786b58a90cf376c05692fe4d6d0712946337

[Daniel van Vugt (vanvugt)]

Xmir (through no choice of its own) is told to destroy all resources (destroy xmir_screen) when the last client disconnects. We could make Xmir leak its resources (including the connection to the Mir server)... that would also solve some annoying flickering but I'm not sure it's the right answer.

[Daniel van Vugt (vanvugt)]

BTW, I've been hacking Xmir for a week and a half and cannot reproduce this bug yet. Although I have been using Mir 0.15 (wily) the whole time too. So Incomplete.

[Christopher Townsend (townsend)]

I still see this issue when launching gedit from a Unity 8 desktop session.

I'm not really sure what the correct solution is, but as a workaround, I can open the X display in the libertine-launch program before launching any other application and then close it after the application exits. This will at least hold a resource open and not kill the Xmir window.

[Robert Ancell (robert-ancell)]

I think holding a connection from libertine-launch to XMir is a good idea - this is what LightDM does anyway for the X servers it spawns.

[Daniel van Vugt (vanvugt)]

Reworded and confirmed.

Although if there ever were any crashes related to this bounce, they have probably been fixed now.

The only remaining annoying part about this bug I can see is if you use non-rootless mode; resize the root window and then lose your last X client. The Mir connection+window gets recreated fullscreen again, instead of the size you made it.

That all said, just keeping non-zero X clients running is a sufficient workaround. The bug is not a problem at all in -rootless mode because you never see the root window when it does go away and return. For non-rootless if you're running a desktop (e.g. nautilus) and/or any window manager, any of those are enough to keep the connection alive. So I don't see any major problem here that anyone will see in reality.