Some Mir clients spin at 100% CPU if the server dies

Bug #1340120 reported by Jean-Baptiste Lallement
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Medium
Alexandros Frantzis
0.7
Fix Released
Medium
Alexandros Frantzis
mir (Ubuntu)
Fix Released
Medium
Unassigned
qtmir (Ubuntu)
Invalid
Undecided
Unassigned
unity-mir (Ubuntu)
Invalid
Undecided
Unassigned
unity8 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

From time to time, some application uses 100% CPU but is not running in foreground (not even in the list of recent application on the application scope)

For example, in the top output below gallery-app uses 100% CPU, but it is not 'launched' (not in recent apps)

top - 12:09:39 up 2:41, 2 users, load average: 1,82, 1,48, 2,31
Tasks: 250 total, 1 running, 246 sleeping, 3 stopped, 0 zombie
%Cpu(s): 3,1 us, 5,5 sy, 0,6 ni, 90,2 id, 0,6 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 1878580 total, 1775476 used, 103104 free, 33104 buffers
KiB Swap: 524284 total, 2144 used, 522140 free. 1023324 cached Mem

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 3895 phablet 20 0 302372 96608 40712 S 117,0 5,1 22:21.13 gallery-app
15556 phablet 20 0 5820 1088 752 R 35,6 0,1 0:00.13 top

I attached the output of strace for the gallery-app.
It is not specific to the gallery-app, I noticed this behavior with system-settings too.

I didn't find any pattern to reproduce this problem reliably.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: unity8 7.90+14.10.20140709.2-0ubuntu1
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.14.4-0ubuntu1
Architecture: armhf
Date: Thu Jul 10 11:56:49 2014
InstallationDate: Installed on 2014-07-10 (0 days ago)
InstallationMedia: Ubuntu Utopic Unicorn (development branch) - armhf (20140710-020204)
SourcePackage: unity8
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
summary: - Application uses 100% CPU but it not running in foreground
+ Application uses 100% CPU but is not running in foreground
description: updated
Revision history for this message
Michael Zanetti (mzanetti) wrote : Re: Application uses 100% CPU but is not running in foreground

This looks like the app was running, then unity crashed and the app is now running around like a headless chicken.

Revision history for this message
Gerry Boland (gerboland) wrote :

Adding Mir as affected project, as when a mir server dies, the clients can hang around and behave poorly (some crash, others sit and poll continually causing 100% CPU usage like this bug).

A correct fix would be for clients to re-connect to a new mir server instance when it becomes available. Obviously a client not using 100% CPU would be a good thing while the new mir instance is spawning.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

This morning there are 2 processes that use 100% CPU and no unity8 crash (or any other application):
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 6640 phablet 20 0 274332 55128 28400 S 95,7 2,9 3:15.64 address-book-ap
 6794 phablet 20 0 317832 54952 37480 S 76,6 2,9 3:30.50 camera-app

The load is more than 2 and the device has been rebooted 1 hour ago with image 138
 09:30:37 up 1:04, 2 users, load average: 2,38, 1,82, 1,06

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Confirmed. Happens with mir_demo_client_fingerpaint too. Kill the server and the client spins at 100%.

summary: - Application uses 100% CPU but is not running in foreground
+ Some Mir clients spin at 100% CPU when the server dies
Changed in mir:
status: New → Triaged
importance: Undecided → Medium
summary: - Some Mir clients spin at 100% CPU when the server dies
+ Some Mir clients spin at 100% CPU if the server dies
Changed in qtmir:
status: New → Invalid
Changed in unity8 (Ubuntu):
status: New → Invalid
Changed in unity-mir (Ubuntu):
status: New → Invalid
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

There are quite a few problems to solve if you want a client to reconnect. Either it would have to remember or just lose the surface state information that is stored on the server.

But we don't have to consider such an enhancement yet to resolve this bug. Just returning errors to the client and letting it close gracefully would be enough.

Changed in mir (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This bug seems to have been fixed by a combination of changes, the last of which was:
   lp:~mir-team/mir/fix-1353867-sigterm-dispatch-mirteam

Fix pending for 0.7.0.

Changed in mir:
assignee: nobody → Alexandros Frantzis (afrantzis)
status: Triaged → Fix Committed
milestone: none → 0.8.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix committed to lp:mir/0.7 at revision 1863, scheduled for release in Mir 0.7.0. I think...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix released to Ubuntu in:
mir (0.7.0+14.10.20140829-0ubuntu1) utopic; urgency=medium

Changed in mir (Ubuntu):
status: Triaged → Fix Released
Changed in mir:
milestone: 0.8.0 → none
status: Fix Committed → Fix Released
Michał Sawicz (saviq)
affects: qtmir → qtmir (Ubuntu)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.