Power dialog shown on resume with big backgrounds or high load

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

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.

please fix _after_ RTM in an OTA

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.

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.

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

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

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

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.

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.

the dupe was targeted so updating this one to get released

just need to target the next ww milestone

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.

raising to crit

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

@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.

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

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.

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

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.

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.

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.

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

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

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.

(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.)

track in new bugs