Power dialog shown on resume with big backgrounds or high load

Bug #1383277 reported by Michał Sawicz on 2014-10-20
46
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Critical
Kevin Gunn
unity8 (Ubuntu)
Medium
Michael Terry
unity8 (Ubuntu RTM)
High
Michał Sawicz

Bug Description

Unfortunately no good steps to reproduce, other than "resume your phone", from time to time you'll get the power dialog displayed on screen.

The reason for this could be twofold: a) you pressed the power button in your pocket b) input is confused and keyUp event does not reach unity8.

Related branches

Launchpad Janitor (janitor) wrote :

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

Changed in unity8 (Ubuntu):
status: New → Confirmed
Michael Terry (mterry) wrote :

It seems to be due to a greeter.showNow() call that takes a long time to return, delaying the handling of the power button release, which would stop the dialog from appearing. Investigating exactly why that call takes a while.

Michael Terry (mterry) on 2014-10-21
Changed in unity8 (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Michael Terry (mterry)
Olli Ries (ories) wrote :

please fix _after_ RTM in an OTA

tags: added: ota-future rtm14
Dave Morley (davmor2) wrote :

The only thing I've noticed is this seems to happen mostly after the phone has been inactive for some time. Also the speed of the phone seems to slow considerably too.

kevin gunn (kgunn72) on 2014-11-06
Changed in unity8 (Ubuntu RTM):
assignee: nobody → Michael Terry (mterry)
status: New → In Progress
importance: Undecided → Medium
Changed in unity8 (Ubuntu):
importance: Undecided → Medium
Michał Sawicz (saviq) wrote :

This seems to be happening when dbus-daemon hogs the CPU, looks like the key down/up events are blocked in a queue somewhere and arrive in a span longer than 2s, making the dialog show up.

Michał Sawicz (saviq) wrote :

Unlinking the branch, as I really doubt it has anything to do with this.

Changed in unity8 (Ubuntu):
status: In Progress → Triaged
Changed in unity8 (Ubuntu RTM):
status: In Progress → Confirmed
status: Confirmed → Triaged
Changed in unity8 (Ubuntu):
assignee: Michael Terry (mterry) → Michał Sawicz (saviq)
Changed in unity8 (Ubuntu RTM):
assignee: Michael Terry (mterry) → Michał Sawicz (saviq)
Michael Terry (mterry) wrote :

In my experience, this was because we load the greeter synchronously, blocking handling of the power-release event. If loading the greeter took longer than 2s, the dialog would come up because it never saw the power-release event. And often loading the background image could slow that down enough for 2s. Or maybe that dbus-daemon hogging the CPU could also exacerbate it.

But the branch that was linked *was* relevant because it made the problem exceedingly difficult to experience (I never did), despite the fact that it didn't *fix* the problem of synchronously loading. But with the linked branch [1] we are just loading QML code instead of image files, which is small enough to not delay loading over 2s.

Simply making the greeter load async (by setting "asynchronous: true" on its loader) is actually a little tough, because of timing issues.

[1] https://code.launchpad.net/~mterry/unity8/cache-greeter-bg/+merge/239144

Michał Sawicz (saviq) wrote :

OK, so that branch fixes one instance of the problem.

Michał Sawicz (saviq) wrote :

I've added some debugging code to my unity8 and here's the output from when I just saw this happen:

[times are in ms]
qml: =============== Power pressed: 1416822034134 false
qml: ================ Timer restarted 1416822034135
qml: =============== Power status changed: 1416822034272 0 2
qml: ================ Dialog shown 1416822036630
qml: =============== Power released: 1416822036762 false

So as can be seen here the dialog is actually shown on *suspend*, not resume. There's a 2.6s delay between the press and release events, even though the key has been released within 150ms (hence the power status change). Not sure where the event could get delayed like that, yet.

Michael Terry (mterry) wrote :

I thought I mentioned in comment #7 that I had already debugged this to that point. The delay is happening in the handling of the power down-press. The call to greeter.show() is synchronous, and Qt seems to block handling of the power-up event until the show() call (and thus the power-down press event) is done. So if greeter.show() takes too long (as it freequently does when we load the background from disk), we trigger the 2s timeout for the shutdown dialog.

Michał Sawicz (saviq) on 2014-11-24
Changed in unity8 (Ubuntu):
status: Triaged → In Progress
assignee: Michał Sawicz (saviq) → Michael Terry (mterry)
Pat McGowan (pat-mcgowan) wrote :

the dupe was targeted so updating this one to get released

Changed in canonical-devices-system-image:
importance: Undecided → High
milestone: none → ww51-2014
status: New → Confirmed
Michał Sawicz (saviq) on 2014-12-05
Changed in unity8 (Ubuntu RTM):
assignee: Michał Sawicz (saviq) → nobody
milestone: none → 14.09-ota-1
Michał Sawicz (saviq) on 2014-12-10
Changed in unity8 (Ubuntu RTM):
importance: Medium → High
kevin gunn (kgunn72) wrote :

just need to target the next ww milestone

Changed in canonical-devices-system-image:
status: Confirmed → New
Changed in canonical-devices-system-image:
milestone: ww51-2014 → ww03-2015
status: New → Confirmed
Pat McGowan (pat-mcgowan) wrote :

I am seeing this very consistently for the first time on mako with the most recent image. The usual symptom is pressing the button first time to resume does nothing, pressing again immediately turns the screen on then off again, the next press shows the shutdown dialog. This only happens when the phone actually sleeps, i.e. it never happens when plugged into usb.

Pat McGowan (pat-mcgowan) wrote :

raising to crit

Changed in canonical-devices-system-image:
importance: High → Critical
John McAleely (john.mcaleely) wrote :

if it's of interest, the dupe #1398782 appears to have logs and a possibly related crash.

Michał Sawicz (saviq) on 2015-01-08
Changed in unity8 (Ubuntu RTM):
assignee: nobody → Michał Sawicz (saviq)
status: Triaged → In Progress
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Michael Terry (mterry) wrote :

@John, I'm not convinced that bug 1398782 is a dup. It may have some similar behavior (a power dialog appearing) but this bug here isn't about a crash or incoming calls.

Pat McGowan (pat-mcgowan) wrote :

I think that dupe is maybe 3 bugs, this one, a unity8 crash since fixed and the dbus-daemon spinning on resume issue (bug #1394204) which is about to land

Michael Terry (mterry) wrote :

It appears there are multiple ways to reproduce the same symptom, which may be several different technical fixes. Here is one:

1) Download and set https://launchpadlibrarian.net/187754062/mountain.jpeg as your phone's background image.

2) In an "adb shell", run:

(while true; do true; done) & (while true; do true; done) & (while true; do true; done) & (while true; do true; done) &

This will max out the four CPUs on a krillin device. (It would be nice if the 'stress' package was available for ubuntu-rtm. Is there a smarter way to do the above? Something that wouldn't involve manually killing the forked jobs?)

3) Now from the dash, suspend the device.
4) Wait a few seconds.
5) Turn the device on.

About 80% of the time, you will see the power dialog.

The lp:~mterry/unity8/power-button-on-lock branch should fix this. But it seems there are other ways to trigger the power dialog, something to do with roaming and sms messages. So I'm still looking at this bug. Clear reproduction steps for the other ways would be great.

Pat McGowan (pat-mcgowan) wrote :

I have used this to stress the cpu

wget https://launchpad.net/ubuntu/+archive/primary/+files/stress-ng_0.03.02-1_armhf.deb
stress-ng --cpu 4 --io 4 --vm 2 --vm-bytes 128M --fork 4

Michael Terry (mterry) wrote :

So I've also seen this symptom on my everyday phone (rtm/mako). It's not due to a large wallpaper image, as I use the stock one. But it does seem to happen when the phone's been running for a long time. So maybe high memory use? And the symptom is that I press the power button to turn the screen on, but nothing happens. Then after a few seconds, I press the power button again and I can see the screen turn on and then off again. So I press the power button a third time and it's fine.

So I'm guessing that somewhere in our handling of the power-on press, we hit the same problem as the "greeter-show block" I fixed in the other branch. We're blocking on something that isn't completing while handling the power-button pressed event. Preventing us from handling the "power-button release event" and then causing us to show the shutdown dialog.

I reproduced with the following steps:
0. The device must be unplugged from usb or power supply and connected to a wifi network.
1. open the network indicator
2. Switch wifi off from the indicator
3. Immediately suspend the device with the power button before the device switches to cellular data
4. Wait a moment (30s) until the device is really suspended
5. Press the power button to resume

Actual result:
The shutdown dialog is displayed.

Note: It doesn't happens systematically but still rather frequently with this test case.

Attached is the output of dbus-monitor --system when this bug is triggered.

Michael Terry (mterry) wrote :

Ooh, jibel, will try that in a sec. Wanted to write down the results of my "walking around Boston for a bit" strategy first.

Two makos:
 - MakoA with ubuntu-touch/ubuntu-rtm/14.09-proposed 160 (i.e. 20150112). Has a cellular plan but no data.
 - MakoB with ubuntu-touch/stable 13 (i.e. 20150109). Has a cellular plan with data.

MakoB has a history of reproducing this (but is my dogfood phone so I don't poke and prod it much). Haven't reliably produced on MakoA before.

Walking around Boston, I got MakoB to hit the comment-20-bug once, when I was walking by a Starbucks where it had connected before. The indicator icon had not switched from the 3G to the wifi icon yet. This matches what others have reported about leaving wifi areas. Sounds like switching between wifi and cellular data is a trigger.

Still could not make MakoA hit it.

-----

A note on false-positives when looking to reproduce this bug. There are two flaws with the same looking symptom. The "comment-18 flaw" can be distinguished from the "comment-20 flaw" by how long it takes the phone display to turn on. If it takes a long time (like >6s), it's probably comment-20. The comment-18 flaw does *not* need a weird wallpaper image to reproduce. It just needs your device to be experiencing slowdown. Hopefully the comment-18 fix lands in RTM soon so there will be less false-positives for comment-20. I myself saw the comment-18 flaw several times in my walk. But only one comment-20 flaw.

Michael Terry (mterry) wrote :

jibel, I've not been able to reproduce your way yet, on my MakoB. Seeing what happens when the wifi changes over to 3G (looks like a bit of churn in the indicators and over dbus that add to system load), are you sure that you're seeing comment-20-style recovery? (i.e. first power button doesn't turn on screen, you press it again only to see screen turn on then off immediately. Then a third press turns screen on for real.)

Or are you seeing comment-18-style recovery? (where the screen comes on relatively fast the first time)

I'm seeing comment-18-style recovery but with the default wallpaper. This is on krillin #191 with 2 SIM cards.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity8 - 8.02+15.04.20150113~rtm-0ubuntu1

---------------
unity8 (8.02+15.04.20150113~rtm-0ubuntu1) 14.09; urgency=medium

  [ Albert Astals ]
  * Use QImageReader not to load the image into memory twice
  * Don't create the whole current scope delegates, just height * 3 (LP:
    #1384393)
  * Make CroppedImageSizer async
  * Rework how we set the ranges so we get some more asynchronousity
    from item views
  * Make sure changing a scope doesn't trigger creation/destruction of
    delegates until it's finished

  [ Michael Terry ]
  * Don't block handling power events on loading the greeter's qml and the
    background image. (LP: #1383277)
 -- Ubuntu daily release <email address hidden> Tue, 13 Jan 2015 15:18:13 +0000

Changed in unity8 (Ubuntu RTM):
status: In Progress → Fix Released
Michał Sawicz (saviq) wrote :

Michael, I think we should split this other bug out, to allow us to keep the bug status sane.

summary: - Power dialog sometimes shown on resume
+ Power dialog shown on resume with big backgrounds
Changed in unity8 (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Released

jibel, then I think the bug you're seeing is fixed in RTM right now. Please try upgrading and seeing if it still happens.

Saviq, fair point. I've created bug 1410830 to handle the comment-20 flaw.

Michael Terry (mterry) wrote :

(It's important to note that this bug does not require big backgrounds as the recent title-edit suggests. It just needs high load / slowdown. Larger backgrounds simply added to the slowdown. If the system was already loaded enough, the default background would trigger it just fine.)

summary: - Power dialog shown on resume with big backgrounds
+ Power dialog shown on resume with big backgrounds or high load
Changed in canonical-devices-system-image:
assignee: nobody → Kevin Gunn (kgunn)
milestone: ww03-2015 → none
status: Fix Released → In Progress
milestone: none → ww05-2015
Pat McGowan (pat-mcgowan) wrote :

track in new bugs

Changed in canonical-devices-system-image:
milestone: ww05-2015 → ww03-2015
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers