unity8-dash should be excluded from app lifecycle management

Bug #1379296 reported by Oliver Grawert
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
qtmir (Ubuntu)
Fix Released
Critical
Michał Sawicz
qtmir (Ubuntu RTM)
Fix Released
Critical
Michał Sawicz
unity8 (Ubuntu)
Invalid
Critical
Unassigned

Bug Description

STEPS:
1. Install the BBC NEWS app from the store
2. Go back to the apps scope
3. Open the bbc app browse about a bit
4. Click on a video link
5. let it play for a while
6. Cycle back to the scopes
Scopes then restarts

having a lot of apps open my unity8-dash gets contantly killed along the apps if a certain OOM threshold is reached ... this appears like a system crash of the UI (even though it is desired killing) from a user perspective ...

checking the oom_score_adj values of all running apps i see that the dash has the same high value as all other open foreground apps:

...
11 7960 oxide-renderer
11 7963 oxide-renderer
11 7988 oxide-renderer
300 6170 oxide-renderer
802 12514 unity8-dash
802 6088 webbrowser-app
802 6873 webapp-containe
802 7425 webapp-containe
802 7910 webapp-containe

(the full log can be found at http://paste.ubuntu.com/8526308/ ) given that the dash is one part of our core UI it should be excluded from app lifecycle management (keeping the same oom_score of 10 as unity8 does) so that only actual apps get killed on high memory pressure.

Related branches

Revision history for this message
Michał Sawicz (saviq) wrote :

I think we need to put the dash between the background apps and the foreground app, so that your foreground app doesn't die before the (backgrounded) dash.

The problem is also that the unity8-dash job is respawning, as it's not a "normal" app, so it won't wait until you focus it again to restart... Although that might not be desirable in itself...

And then we need to reduce the mem usage in unity8-dash when people have large music collections (like ogra!).

Changed in unity8 (Ubuntu):
status: New → Triaged
importance: Undecided → High
tags: added: lt-category-visible lt-date-20141009 lt-prio-high
tags: added: lt-blocker
Dave Morley (davmor2)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in qtmir (Ubuntu):
status: New → Confirmed
Dave Morley (davmor2)
Changed in unity8 (Ubuntu):
importance: High → Critical
Changed in qtmir (Ubuntu):
importance: Undecided → Critical
Michał Sawicz (saviq)
Changed in qtmir (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Michał Sawicz (saviq)
Changed in unity8 (Ubuntu):
status: Triaged → Opinion
Alexander Sack (asac)
tags: added: rtm14
Michał Sawicz (saviq)
Changed in unity8 (Ubuntu):
status: Opinion → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtmir - 0.4.4+14.10.20141013-0ubuntu1

---------------
qtmir (0.4.4+14.10.20141013-0ubuntu1) utopic; urgency=medium

  [ Daniel d'Andrada ]
  * Turn UbuntuKeyboardInfo into a QML singleton

  [ Gerry Boland ]
  * Rewrite DesktopFileReader to use GDesktopAppInfo, enables reading
    localized keys (LP: #1350360)

  [ Michał Sawicz ]
  * Ensure unity8-dash is less likely to be killed than other background
    apps. (LP: #1379296)

  [ Robert Carr ]
  * Pass key auto-repeat flag through QtEventFeeder.
 -- Ubuntu daily release <email address hidden> Mon, 13 Oct 2014 10:08:04 +0000

Changed in qtmir (Ubuntu):
status: In Progress → Fix Released
Changed in qtmir (Ubuntu RTM):
importance: Undecided → Critical
assignee: nobody → Michał Sawicz (saviq)
Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

In theory, this landed and is in rtm krillin image 112... but on 112 I've had unity8 get OOM-killed twice in the past couple hours.

The first time, posclientd basically freaked out (sorry, vague) and pegged the CPU, and soon afterward unity8 got OOM killed. For that matter, apport failed too, due to insufficient memory.

The second time, media-hub went into a similar resource-hogging loop and unity8 got killed... and apport was again unable to get a useful result due to memory.

So... not actually fixed?

Revision history for this message
Oliver Grawert (ogra) wrote :

if the dash would not be in lifecycle management at all and you would have gotten your system in such a state, the kernel would just have randomly killed bits of your session instead of the dash.

it is wanted that in such cases the dash gets killed before i.e. ofono gets killed so that your session still stays functional.
imho the behavior is just fine, in case the sysem functions normal it should be the last of your UI apps that gets killed.
in case where not even that would free up enough memory you have a whole lot of bigger probs ... the bug here lies within the apps that consume all your ram where they should not.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtmir - 0.4.4+15.04.20141030.2~rtm-0ubuntu1

---------------
qtmir (0.4.4+15.04.20141030.2~rtm-0ubuntu1) 14.09; urgency=low

  [ Ted Gould ]
  * Use UAL pause/resume functions for stopping/continuing all tasks in
    the cgroup (LP: #1379786)

  [ Timo Jyrinki ]
  * Add libmtdev-dev build dependency (LP: #1379152) (LP: #1379152)
 -- Ubuntu daily release <email address hidden> Thu, 30 Oct 2014 21:48:30 +0000

Changed in qtmir (Ubuntu RTM):
status: New → Fix Released
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.