Closed Bug 836427 Opened 11 years ago Closed 11 years ago

B2G crash in liboemcamera

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-b2g:-, b2g18+)

RESOLVED WORKSFORME
blocking-b2g -
Tracking Status
b2g18 + ---

People

(Reporter: marcia, Unassigned)

References

Details

(Keywords: crash, reproducible, Whiteboard: [b2g-crash])

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-fedf72b6-ed34-4021-ad1f-2dbcc2130130 .
============================================================= 

Seen while running, unagi,
gecko revision="066b9d7cf30884a001db22bde3ae939c02718062"
gaia revision="f7f5a0cd17e3d04308cc5850b254947e127122b9"

STR:
1. Put the camera face down after taking a picture. While I was putting it down I could still hear the shutter firing.
2. Received the attached crash

Reproduced on two different devices one time, since then I haven't been able to repro on the same devices.
Whiteboard: [b2g-crash]
In the report I found following.

>Thread 14
>8 libxul.so 	mozilla::GonkCameraHardware::ReleaseHandle 	CameraHardwareInterface.h:430
>9  libxul.so 	mozilla::nsGonkCameraControl::ReleaseHardwareImpl 	GonkCameraControl.cpp:1331 

From the log, it seems that camera hw was freed during taking a photo.
Whiteboard: [b2g-crash]
I found following STR to camera app crash.

STR:
1. Start Camera app by touching Camera icon
2. touch "take a picture" button
3. soon after touch "home" button

repeat [1] [2] [3] quickly, I can easily reproduce camera app crash.
I conformed the crash on unagi phone with today's source.
Whiteboard: [b2g-crash]
Keywords: reproducible
Current hypothesis:
1. JS calls TakePicture()
2. app is hidden, JS calls ReleaseHardware()
3. camera calls DataCallback() with the result of TakePicture()
4. callback returns image to JS, which calls RestartPreview()
--- except at this point, the hardware has been released
blocking-b2g: --- → tef?
With B2G_DEBUG=1, I see the following assertion:

F(  443:0x1bb) Assertion failure: !ForkJoinSlice::InParallelSection(), at /home/mikeh/dev/mozilla/m-c/inbound-src/js/src/jsgc.cpp:4398

This line is a JS_ASSERT, which is #defined as MOZ_ASSERT.  The latter does nothing in non-debug builds, but in debug builds, is calls MOZ_CRASH(), which is the fatal SIGSEGV seen in the logcat.

This is _different_ from the crash seen in non-debug builds.
It took a while, can confirm the crash in gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1203.1449]
0x42de26da in snapshot_start ()
   from /home/mikeh/dev/mozilla/btg019/out/target/product/unagi/system/lib/liboemcamera.so
(gdb) bt
#0  0x42de26da in snapshot_start ()
   from /home/mikeh/dev/mozilla/btg019/out/target/product/unagi/system/lib/liboemcamera.so
#1  0x40110144 in _normal_unlock (mutex=0x42e6b668) at bionic/libc/bionic/pthread.c:973
#2  pthread_mutex_unlock (mutex=0x42e6b668) at bionic/libc/bionic/pthread.c:1120

The rest of the backtrace is unusable.
Note that the crash occurs in the snapshot thread, which is a very short-lived thread internal to the camera library.
Can we dup this here Inder?
Flags: needinfo?(ikumar)
Can't reproduce this on our devices using STR in Comment 2. I tried more than 20 times and went from quickly doing 1,2 and 3 to more slowly but still no crash. Looks like a device specific issue.
Flags: needinfo?(ikumar)
A potential work-around for the crash we're encountering in liboemcamera.so.  This defers the release of the underlying hardware until all async processes (currently only autoFocus() and takePicture()) are completed.

With this WIP patch, I cannot crash the camera using the above STR.
I can reproduce on unagi with today's build with STR from comment 2.  The home button has to be pressed almost immediately after the picture taking.

The crash doesn't seem to happen on the otoro.
Tracking instead of blocking, given the fact that this is intermittent and we don't have any evidence it isn't recoverable.
blocking-b2g: tef? → -
tracking-b2g18: --- → +
(In reply to Alex Keybl [:akeybl] from comment #12)
>
> Tracking instead of blocking, given the fact that this is intermittent and
> we don't have any evidence it isn't recoverable.

There is evidence that it's a bug in our (old--dated Oct 2012) version of the camera library.
marcia, do you still see this issue?
Flags: needinfo?(mozillamarcia.knous)
Component: Gaia::Camera → General
Not seeing it on 1.0.1 with Commercial RIL, and not seeing it on V1 train build either, Commercial RIL.
Flags: needinfo?(mozillamarcia.knous)
I'm going to close this then. Please reopen if this shows up again.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: