[xmir] closing an app while a child window is opened leaves an Xmir process opened eating 100% CPU

[dinamic]

Ubuntu 17.04 Unity 8
[xmir] closing an app while a child window is opened leaves an Xmir process opened eating 100% CPU

launch solitaire (just click on the sol icon from launcher, it will just run on Xmir)
open the about window from the menu (Help \ About)
now close the main window

now top in a terminal (see attached)

[Michał Sawicz (saviq)]

Sorry, wrong bug...

[Stephen M. Webb (bregma)]

This is simple to reproduce. The application has disappeared from the screen but continues to run.

It looks like qtmir is closing the window (as requested) but no word gets out to the actual process (ie. there is no session management). I'm suspecting the Unity 8 lifecycle for desktops is not in place yet.

Here's a snippet from $HOME/.cahe/upstart/unity8.log.

[2017-03-20:19:34:52.953] qtmir.sessions: TaskController::onSessionStarting - sessionName=sol^M
[2017-03-20:19:34:52.954] qtmir.applications: Application["sol"]::setSession(session=qtmir::Session(0x4ecb3290))^M
[2017-03-20:19:34:53.457] file:///usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/1.3/Icon.qml:115:5: QML Image: Cannot open: file:///home/stephenw/.face^M
[2017-03-20:19:34:57.992] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::MirSurface(type=normal,state=restored,size=(480,376),parentSurface=QObject(0x0))^M
[2017-03-20:19:34:58.015] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::registerView(268052752) after=1^M
[2017-03-20:19:34:58.032] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::setKeymap("us")^M
[2017-03-20:19:34:58.467] toplevelwindowmodel: prependSurface appId=sol surface=qtmir::MirSurface(0x3c828f80), filling out placeholder. after: (index=0,appId=sol,surface=0x3c828f80,id=11),(index=1,appId=unity8-dash,surface=0x225db2f0,id=4)^M
[2017-03-20:19:34:58.468] toplevelwindowmodel: setFocusedWindow(0x0)^M
[2017-03-20:19:34:58.499] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::setFocused(true)^M
[2017-03-20:19:34:58.514] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::setReady()^M
[2017-03-20:19:34:58.520] qtmir.applications: Application["sol"]::setInternalState(state=Running)^M
[2017-03-20:19:34:58.537] toplevelwindowmodel: setFocusedWindow(Window[0x28c28060, id=11, MirSurface[0x3c828f80,"AisleRiot"]])^M
[2017-03-20:19:34:58.664] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::requestState(restored)^M
[2017-03-20:19:34:58.673] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::updateExposure(true)^M
[2017-03-20:19:35:19.651] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::MirSurface(type=menu,state=restored,size=(172,66),parentSurface=qtmir::MirSurface(0x3c828f80))^M
[2017-03-20:19:35:19.801] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::registerView(745266864) after=1^M
[2017-03-20:19:35:20.080] qtmir.surfaces: MirSurface[0x3c828f80,"sol"]::setFocused(false)^M
[2017-03-20:19:35:20.093] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::setFocused(true)^M
[2017-03-20:19:35:20.098] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::setReady()^M
[2017-03-20:19:35:20.123] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::updateExposure(true)^M
[2017-03-20:19:35:20.126] toplevelwindowmodel: setFocusedWindow(Window[0x33e53dc0, id=12, MirSurface[0x28beec90,"AisleRiot"]])^M
[2017-03-20:19:35:20.128] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::setKeymap("us")^M
[2017-03-20:19:35:23.549] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::setLive(false)^M
[2017-03-20:19:35:23.552] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::unregisterView(745266864) after=0 live=false^M
[2017-03-20:19:35:23.553] qtmir.surfaces: MirSurface[0x28beec90,"sol"]::updateExposure(false)^M
[2017-03-20:19:35:23.555] qtmir.surfaces:...

[Daniel van Vugt (vanvugt)]

I spent a little time on this bug last week.

Was able to reproduce it, yes, but the spinning thread was apparently the libmirclient input thread, and not in any Xmir code. I didn't have sufficient libmirclient symbols to debug it further before running out of time. I had assumed this was an Xmir bug but it looks like it might actually be a Mir bug.