Preview frozen after unlocking

[Pat McGowan]

[Procedures]
1 open the camera app
2 lock screen on the camera view interface by pressing power button
2.unlock the screen

[Expect results]
camera screen display normally
[Actual results]
The preview image is frozen for about 5 secs

[Reproduce]
May need to do 5 to 10 times
Once in this state it seems to then happen consistently

[Bill Filler (bfiller)]

I did some testing. I am seeing two different behaviors:
1) "Normal" behavior: when the phone is locked/unlocked, the viewfinder shows black for ~1 second and then switches back to live viewfinder mode. This is expected, as the camera-app has to release the camera backend when it becomes inactive (either from moving to the background or locking the phone) such that other apps using the camera will have it available. Only one client connection at a time is allowed and this how Android subsystem we are using is designed.

2) Abnormal behavior: hard to reproduce, but sometimes after lock/unlock the viewfinder shows a frozen image of the previous preview for ~5seconds, then switches to black screen, then to a live viewfinder. Cannot always reproduce this but assuming this is the bug that has been reported.

@victor
Can you confirm that 2) is the case that is being reported?

[Florian Boucault (fboucault)]

The only way I can see 2) happening is if the system is overloaded (possibly due to a memory leak or due to a rogue process using CPU when it shouldn't) then the camera app will not have enough time to release the lock on the camera and clear the viewfinder's preview before the process is suspended/interrupted.

[Jim Hodapp (jhodapp)]

I would think that's highly unlikely though since a process has 5 seconds from the point that it receives a signal that it's being suspended until the point that it actually is suspended. 5 seconds is a long time in computing.

[Bill Filler (bfiller)]

Maybe it's only occurs if you lock/unlock very fast, where the camera is still in process of shutting down when it's asked to re-initialize? Lets look into the code to see what would happen in that case to make sure it's not causing the freeze symptom.

[Bill Filler (bfiller)]

Here is syslog from Pat's krillin when he got 2) error from above:
http://paste.ubuntu.com/9373379/

[Pat McGowan (pat-mcgowan)]

I reproduced fairly quickly as follows:

Phone is unplugged from USB
Lock the phone and resume several times, all fine.
Press power and this time allow at least 1 min for it to suspend
Resume phone, first time is ok
Lock - pause - resume second time phone screen locks up
Try again and screen locks again, it seems to stay in the bad state for awhile.

[Pat McGowan (pat-mcgowan)]

fwiw I have a passcode enabled

[Bill Filler (bfiller)]

I got freeze same way Pat said. The key seems to be to let it suspend for > 1 minute then on the second resume it freezes

[Florian Boucault (fboucault)]

Steps to reproduce

0) make sure that USB is unplugged
1) launch camera
2) lock phone and wait 5 seconds
3) resume phone and wait 5 seconds
4) unlock phone

Expected result:
Depending on how fast the phone was unlocked the camera is either fully functional with the camera viewfinder showing the camera video feed or a black screen is shown for a split second before the camera becomes functional.

Current result:
The camera app is not rerendered for a few seconds.
The process is not suspended anylonger as expected but:
 a) Qt.application.active is not set to true for a few seconds
 b) no rendering occurs for that period of time
 c) inputs are not taken into account for that period of time (but they are reliably delivered once the application unfreezes)

Important notes:
- This happens on krillin with both RTM and vivid
- This does not happen on mako
- It happens with a freshly flashed phone and once reproduced tends to happen more often
- It happens with a just rebooted phone with no other app (other than Unity8) running
- When it happens the greeter screen's background usually is black for a split second upon resuming the phone
- It happens even with MIR_SERVER_DISABLE_OVERLAYS=true
- No piece of code in the stack seems to be setting eglSwapInterval(0) (it is one by default for all apps)
- It was not possible to reproduce it so far with other apps
- The stack traces of the app in the normal case and the broken case seem identical (Normal bt: http://pastebin.ubuntu.com/9474590/ & Frozen bt: http://pastebin.ubuntu.com/9474521/ ) suggesting that the camera process itself is behaving normally

[Florian Boucault (fboucault)]

Additional information:
- Tagger is also affected by that bug
- Previous note about rendering not happening was incorrect, rendering is happening as expected while the app is 'frozen'
- A sample minimal app for which the bug happens is available at: https://code.launchpad.net/~fboucault/+junk/camerafreeze

[Florian Boucault (fboucault)]

Interestingly, the following video player bug is reminiscent of this one: https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1398564

[Bill Filler (bfiller)]

After discussion, seems the issue is that powerd suspends the device as soon as the power button is pressed and the screen lock is released. The suspend happens before the app manager can tell the apps they are inactive, so the camera-app is not able to properly release the camera. When resume happens the camera-app then releases after some time and restarts.

[Florian Boucault (fboucault)]

It looks like an older bug would represent a possible solution to the deep suspend: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1309915

[Florian Boucault (fboucault)]

Same cause triggers media player bug https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1398564