817141 - camera preview doesn't work from lockscreen; camera remains broken even when unlocked

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Camera, defect, P1)

Description

[David Flanagan [:djf]]

If I don't have a passcode on my phone, then clicking the camera button on the lockscreen just unlocks the phone and runs the camera as usual. This is fine.

But if there is a passcode, the camera button is supposed to run a special lockscreen version of the camera.  When I try this, the camera opens up but the preview screen remains black and I cannot take pictures.

The weird thing is that this continues even after I unlock the phone and try to use the regular camera app.  Black preview screen.  Even killing and restarting the camera app doesn't help.  The only thing I've found that gets the camera working again is a reboot.  And it works okay as long as I don't try to start it from the lockscreen.

The fact that killing and restarting the app doesn't fix the problem suggests to me that the hardware is getting into some kind of broken state...

Comment 1

[David Flanagan [:djf]]

I see this on my Unagi, by the way.

Comment 2

[Joe Cheng [:jcheng] (please needinfo)]

BB+, P1 - doesn't work for those who have passcode. Reproduced by several people in the triage meeting

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

On today's tip, the camera works (preview, taking pictures) when started from the lock screen, on an unagi with a passcode set.  But... 

If I press the Home button to return to the lock screen, and then open the camera again--or unlock the phone and tap on the camera icon--the phone crashes.  I'm working on narrowing down where this is happening, but the log seems to show:

I/        (  527): Destroying camera 0
E/QualcommCamera(  527): Qint android::close_camera_device(hw_device_t*): device =0x4beee100 E
I/QualcommCamera(  527): void android::close_Hal_obj(camera_device*): E
I/QualcommCamera(  527): void android::close_Hal_obj(camera_device*): clear hw
I/QualcommCameraHardware(  527): ~QualcommCameraHardware E
V/QualcommCameraHardware(  527): ~MMCameraDL: E
V/QualcommCameraHardware(  527): closed MM Camera DL 
V/QualcommCameraHardware(  527): ~MMCameraDL: X
I/QualcommCameraHardware(  527): ~QualcommCameraHardware X
I/QualcommCamera(  527): void android::close_Hal_obj(camera_device*): X
D/memalloc(  527): /dev/pmem_adsp: Freeing buffer base:0x47ff4000 size:233472 fd:161
F/libc    (  527): Fatal signal 11 (SIGSEGV) at 0x5a5a5a5a (code=1)
I/Gecko   (  568): [Child 568] WARNING: shutting down early because of crash!: file /home/mikeh/dev/mozilla/btg015/gecko/dom/ipc/ContentChild.cpp, line 786
I/Gecko   (  568): [Child 568] WARNING: content process _exit()ing: file /home/mikeh/dev/mozilla/btg015/gecko/dom/ipc/ContentChild.cpp, line 831
I/DEBUG   (  528): debuggerd committing suicide to free the zombie!
I/DEBUG   (  630): debuggerd: Nov 27 2012 18:53:42

Comment 4

[Mike Habicher [:mikeh] (high bugzilla latency)]

Okay, I can reproduce this without a passcode:
1. from the home screen, launch the camera app
2. once the preview comes up, press the Home button
3. press the power button to turn off the display
4. press the power button again to wake the display
5. unlock the device
6. tap on the camera app icon again to (re)launch it
--- camera comes up with blank preview

logcat:
E/QualcommCamera(  699): Qint android::get_number_of_cameras(): E
I/QualcommCameraHardware(  699): getCameraInfo: IN
I/QualcommCameraHardware(  699): getCameraInfo: loading libqcamera at 0xb000e9c8
V/QualcommCameraHardware(  699):  Storing the current target type as 3 
I/QualcommCameraHardware(  699): getCameraInfo: numOfCameras = 1
I/QualcommCameraHardware(  699): Camera sensor 0 info:
I/QualcommCameraHardware(  699): camera_id: 0
I/QualcommCameraHardware(  699): modes_supported: 5
I/QualcommCameraHardware(  699): position: 0
I/QualcommCameraHardware(  699): sensor_mount_angle: 90
V/QualcommCameraHardware(  699): getCameraInfo: dlclose(libqcamera)
I/QualcommCameraHardware(  699): getCameraInfo: OUT
I/PRLog   (  699): 1075074296[42507160]: getListOfCameras : get_number_of_cameras() returned 1
E/QualcommCamera(  699): Qint android::get_camera_info(int, camera_info*): E
I/QualcommCameraHardware(  699): Found a matching camera info for ID 0
I/QualcommCameraHardware(  699): HAL_getCameraInfo: orientation = 90
I/QualcommCameraHardware(  699): HAL_getCameraInfo: modes supported = 5
D/memalloc(  531): /dev/pmem: Freeing buffer base:0x4abbc000 size:675840 offset:2498560 fd:148
I/PRLog   (  699): 1075074296[42507160]: virtual nsresult nsDOMCameraManager::GetCamera(const JS::Value&, nsICameraGetCameraCallback*, nsICameraErrorCallback*, JSContext*):126
I/PRLog   (  699): 1075074296[42507160]: mozilla::nsDOMCameraControl::nsDOMCameraControl(uint32_t, nsIThread*, nsICameraGetCameraCallback*, nsICameraErrorCallback*, uint64_t):128 : this=43d6de60
I/PRLog   (  699): 1075074296[42507160]: mozilla::CameraControlImpl::CameraControlImpl(uint32_t, nsIThread*, uint64_t):32 : this=43d2c400
I/PRLog   (  699): 1075074296[42507160]: mozilla::nsGonkCameraControl::nsGonkCameraControl(uint32_t, nsIThread*, mozilla::nsDOMCameraControl*, nsICameraGetCameraCallback*, nsICameraErrorCallback*, uint64_t):201 : this=43d2c400
I/PRLog   (  699): 1075074296[42507160]: InitGonkCameraControl::InitGonkCameraControl(mozilla::nsGonkCameraControl*, mozilla::nsDOMCameraControl*, nsICameraGetCameraCallback*, nsICameraErrorCallback*, uint64_t):158 : this=431c2fd0
I/PRLog   (  699): 1075074296[42507160]: >>> Register( aDOMCameraControl = 43d6de60 ) mWindowId = 0x3
--- appears frozen at this point

*yoink*

Comment 5

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Mike Habicher [:mikeh] from comment #4)
>
> Okay, I can reproduce this without a passcode:
> 1. from the home screen, launch the camera app
> 2. once the preview comes up, press the Home button
> 3. press the power button to turn off the display
> 4. press the power button again to wake the display
> 5. unlock the device
> 6. tap on the camera app icon again to (re)launch it
> --- camera comes up with blank preview

Charming... this only happens when "Out of Process" is enabled.

Comment 6

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Mike Habicher [:mikeh] from comment #5)
>
> Charming... this only happens when "Out of Process" is enabled.

(As in, if OoP is disabled, the camera preview starts properly.)

Comment 7

[Mike Habicher [:mikeh] (high bugzilla latency)]

In the OoP-enabled case, it looks like hitting the Home button doesn't finish stopping the preview.  Instead, the internal libcamera thread seems to block inside android::stop_preview() somewhere after the logcat shows "display lock".  In the OoP-disabled case, we eventually see "display unlock" and the preview thread is stopped.

Once the libcamera thread is blocked, it never unblocks, and a reboot is required.

Comment 8

[Mike Habicher [:mikeh] (high bugzilla latency)]

Last logcat output from the libcamera thread:

I/PRLog   (  403): 1074410744[42507160]: Stopping preview stream
I/PRLog   (  403): 1074410744[42507160]: mozilla::StopPreviewTask::StopPreviewTask(mozilla::CameraControlImpl*):565 : this=4494d840
I/PRLog   (  403): 16356440[44393630]: virtual nsresult mozilla::StopPreviewTask::Run():575
I/PRLog   (  403): 16356440[44393630]: nsresult mozilla::nsGonkCameraControl::StopPreviewInternal(bool): stopping preview (mDOMPreview=448a84c0)
I/PRLog   (  403): 16356440[44393630]: static void mozilla::GonkCameraHardware::StopPreview(uint32_t) : aHwHandle = 1, hw = 44941880
V/        (  403): disableMsgType(0)
E/QualcommCamera(  403): Qvoid android::disable_msg_type(camera_device*, int32_t): E
V/        (  403): stopPreview(0)
E/QualcommCamera(  403): Qvoid android::stop_preview(camera_device*): E
V/QualcommCameraHardware(  403): stopPreview: E
E/QualcommCameraHardware(  403): stopPreview:  Cancelling postview buffer 82 
E/QualcommCameraHardware(  403): stoppreview : display lock

Comment 9

[Mike Habicher [:mikeh] (high bugzilla latency)]

Okay, here is what I believe is going on...

1. when the preview thread is running, it acquires a display lock and calls GNW::dequeueBuffer() to get a new preview buffer
2. the buffer pool is exhausted, so dequeueBuffer() waits on a condition variable
3. the camera thread calling the driver's stopPreview() method also tries to acquire the display lock

The preview thread and camera are now deadlocked _until_ the dequeueBuffer() condition variable is signalled, which for some reason isn't happening.  The following GNW methods signal this variable:
- abandon()
- setBufferCount()
- queueBuffer()
- getCurrentBuffer()
- returnBuffer(), and
- cancelBuffer()

Normally, returnBuffer() is called when CameraGraphicBuffers are disposed of in the viewfinder MediaStream--provided EndTrack()/Finish() are called.

It looks like this bug was introduced by the patch in bug 809259.  I have a fix--just testing to make sure it doesn't regress _that_ fix.

Comment 10

[David Flanagan [:djf]]

The camera app also recently upgraded its devicestorage permissions from readcreate to readwrite, and I just noticed that the system app does not have the corresponding permissions, and does not have video permission at all. This means that even once this bug is fixed, the lockscreen version of the camera will not be able to record a video.  I'll fix that in my pending work in 812924.

Comment 11

[David Flanagan [:djf]]

Mike: I don't suppose the bug you're fixing would affect video playback would it?  I'm converting the camera app to preview its own videos and photos and find that when invoked from the lockscreen, it does not play back videos.  It shows the first frame and the time advances, but the video image does not move.  Sound plays. And if I drag the slider I can seek within the video and get the image to change. But no regular playing happens.

Comment 12

[Mike Habicher [:mikeh] (high bugzilla latency)]

Attachment: Need to call EndTrack()/Finish() from StopPreview() as well

cjones, would you mind reviewing this one as well?  It's a partial unwind of the patch in bug 809259, which in the case djf describes in this bug, causes a deadlock in the camera driver's stopPreview() function.

tl;dr: EndTrack() and Finish() need to be called from whichever of StopPreview() or SetStateStopped() gets called first.

Comment 13

[Mike Habicher [:mikeh] (high bugzilla latency)]

try-server push: https://tbpl.mozilla.org/?tree=Try&rev=98defe0df869

Comment 14

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 688042 [details] [diff] [review]
Need to call EndTrack()/Finish() from StopPreview() as well

This good evidence that I shouldn't have reviewed the first patch.  Kan-Ru should be around in a couple of hours.

Comment 15

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #14)
> 
> This good evidence that I shouldn't have reviewed the first patch.

I don't think any reviewer would have caught that. :) The two failure mechanisms are only very-loosely connected.

Comment 16

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to David Flanagan [:djf] from comment #11)
>
> Mike: I don't suppose the bug you're fixing would affect video playback
> would it?  I'm converting the camera app to preview its own videos and
> photos and find that when invoked from the lockscreen, it does not play back
> videos.  It shows the first frame and the time advances, but the video image
> does not move.  Sound plays. And if I drag the slider I can seek within the
> video and get the image to change. But no regular playing happens.

djf: I assume you mean when invoked from the lockscreen, and no passcode has been set?  Else that could be a serious security breach.

This patch could affect video playback, depending on DSP buffer usage.  If you have a patch I can apply to gaia, I'm happy to try it out.

Comment 17

[Dale Harvey (:daleharvey)]

It will only preview the images that were taken in that instance of the application, photos / videos from storage / previous camera runs wouldnt be accessible.

Actually it doesnt currently but we probably should ensure we clear _photosTaken on mozHidden if in secure mode

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fdc4e064dfcd

Comment 19

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/fdc4e064dfcd

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c02926efc5fa
https://hg.mozilla.org/releases/mozilla-b2g18/rev/e261861b0270

Comment 21

[J Zimbrick]

Issues do not appear to be occurring in Unagi build 20130103070201.

Camera app displayed the proper preview screen using the steps in the comments in the attempts I made.

Verifying as fixed.