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

VERIFIED FIXED in Firefox 19

Status

Firefox OS
Gaia::Camera
P1
normal
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: djf, Assigned: mikeh)

Tracking

unspecified
B2G C2 (20nov-10dec)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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...
(Reporter)

Comment 1

5 years ago
I see this on my Unagi, by the way.
blocking-basecamp: --- → ?
BB+, P1 - doesn't work for those who have passcode. Reproduced by several people in the triage meeting
blocking-basecamp: ? → +
Priority: -- → P1
Assignee: nobody → dale
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
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*
Assignee: dale → mhabicher
Status: NEW → ASSIGNED
(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.
(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.)
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.
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
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.
(Reporter)

Comment 10

5 years ago
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.
(Reporter)

Comment 11

5 years ago
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.
Created attachment 688042 [details] [diff] [review]
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.
Attachment #688042 - Flags: review?(jones.chris.g)
try-server push: https://tbpl.mozilla.org/?tree=Try&rev=98defe0df869
Hardware: x86 → ARM
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.
Attachment #688042 - Flags: review?(jones.chris.g) → review?(kchen)
(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.
(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.
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
Attachment #688042 - Flags: review?(kchen) → review+
Keywords: checkin-needed
Whiteboard: needs-checkin-aurora
https://hg.mozilla.org/integration/mozilla-inbound/rev/fdc4e064dfcd
Keywords: checkin-needed
Whiteboard: needs-checkin-aurora
https://hg.mozilla.org/mozilla-central/rev/fdc4e064dfcd
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
https://hg.mozilla.org/releases/mozilla-aurora/rev/c02926efc5fa
https://hg.mozilla.org/releases/mozilla-b2g18/rev/e261861b0270
status-b2g18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed
Keywords: checkin-needed
Target Milestone: --- → B2G C2 (20nov-10dec)

Comment 21

5 years ago
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.