820139 - camera - crash when switching between camera and camcorder and in between recording videos

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P1)

Description

[Inder]

Attachment: callstack of crash from minidump

STR:
 1. Open camera app, take couple of pics
 2. Switch to camcorder
 3. Record a video
 4. Switch to camera mode
 5. Repeat 2 to 4, until you see a crash

Sometimes hard to reproduce but definitely crashes the camera if done long enough. For me I see a crash if i repeat stpes 2 to 4 about 6 to 7 times.

We are possibly exhausting pmem but it shouldn't happen unless there is a leak.

Comment 1

[Kan-Ru Chen [:kanru] (UTC+9)]

I can't reproduce this on m-c + unagi. I'll try my dogfood phone.

Comment 2

[Kan-Ru Chen [:kanru] (UTC+9)]

I/Gecko   ( 1041): [Child 1041] ###!!! ABORT: [PImageContainerChild] abort()ing as a result: file PImageContainerChild.cpp, line 527

Comment 3

[Kan-Ru Chen [:kanru] (UTC+9)]

I can crash it with just two switch. It doesn't seem to leak pmem.

Comment 4

[Kan-Ru Chen [:kanru] (UTC+9)]

Weird. If I attach gdb to the Camera process, it will crash in the ConfigureRecorder method

(gdb) bt
#0  0x40884002 in mozilla::GonkRecorderProfile::ConfigureRecorder (this=0x0, aRecorder=0x4374c7f0)
    at /home/kanru/zone2/mozilla/central/dom/camera/GonkRecorderProfiles.cpp:102
#1  0x4087cc2e in mozilla::nsGonkCameraControl::SetupRecording (this=0x41a2ed40, aFd=<value optimized out>, aRotation=0, 
    aMaxFileSizeBytes=3827335168, aMaxVideoLengthMs=0) at /home/kanru/zone2/mozilla/central/dom/camera/GonkCameraControl.cpp:1221
#2  0x4087d52c in mozilla::nsGonkCameraControl::StartRecordingImpl (this=0x41a2ed40, aStartRecording=0x42623ba0)
    at /home/kanru/zone2/mozilla/central/dom/camera/GonkCameraControl.cpp:862
#3  0x4087bbba in mozilla::StartRecordingTask::Run (this=0x42623ba0) at /home/kanru/zone2/mozilla/central/dom/camera/CameraControlImpl.h:441
#4  0x40bf0a7a in nsThread::ProcessNextEvent (this=0x43ac0580, mayWait=<value optimized out>, result=0x45648eb7)
    at /home/kanru/zone2/mozilla/central/xpcom/threads/nsThread.cpp:627
#5  0x40bd0c82 in NS_ProcessNextEvent_P (thread=0x4374c7f0, mayWait=true)
    at /home/kanru/zone2/mozilla/B2G/objdir-gecko/xpcom/build/nsThreadUtils.cpp:221
#6  0x40bf0ec4 in nsThread::ThreadFunc (arg=<value optimized out>) at /home/kanru/zone2/mozilla/central/xpcom/threads/nsThread.cpp:265
#7  0x401619f8 in _pt_root (arg=<value optimized out>) at /home/kanru/zone2/mozilla/central/nsprpub/pr/src/pthreads/ptthread.c:156
#8  0x4006fe18 in __thread_entry (func=0x40161999 <_pt_root>, arg=0x43b91dd0, tls=<value optimized out>) at bionic/libc/bionic/pthread.c:217
#9  0x4006f96c in pthread_create (thread_out=<value optimized out>, attr=0xbef0e4e4, start_routine=0x40161999 <_pt_root>, arg=0x43b91dd0)
    at bionic/libc/bionic/pthread.c:357
#10 0x00000000 in ?? ()

Comment 5

[Kan-Ru Chen [:kanru] (UTC+9)]

This is very hard to reproduce on m-c :(

Comment 6

[Kan-Ru Chen [:kanru] (UTC+9)]

logcat:

E/mm-camera( 6840): Waiting for frame thread to start ! 
E/mm-camera( 6840): Wait over, frame thread ready !!!! 
E/mm-camera( 6840): core dump for ctrl->pendingCtrlCmd != NULL, type: 38,  status: 1
E/mm-camera( 6840): ctrlCmd: type: 39, status: 1

gdb:

(gdb) bt
#0  0x42544c8e in config_proc_ctrl_command ()
   from /home/kanru/zone2/mozilla/B2G/out/target/product/otoro/system/lib/liboemcamera.so
#1  0x42543cfa in cam_conf ()
   from /home/kanru/zone2/mozilla/B2G/out/target/product/otoro/system/lib/liboemcamera.so
#2  0x42543cfa in cam_conf ()
   from /home/kanru/zone2/mozilla/B2G/out/target/product/otoro/system/lib/liboemcamera.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Comment 7

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

(In reply to Kan-Ru Chen [:kanru] from comment #4)
> Weird. If I attach gdb to the Camera process, it will crash in the
> ConfigureRecorder method
> 
> (gdb) bt
> #0  0x40884002 in mozilla::GonkRecorderProfile::ConfigureRecorder (this=0x0,
> aRecorder=0x4374c7f0)
>     at
> /home/kanru/zone2/mozilla/central/dom/camera/GonkRecorderProfiles.cpp:102

this=0x0 ?  Assuming this wasn't optimized out, looks like a null pointer.

Comment 8

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

(In reply to Kan-Ru Chen [:kanru] from comment #3)
>
> I can crash it with just two switch. It doesn't seem to leak pmem.

I can confirm this: after a few dozen mode cycles, I still see allocated pmem_adsp fd numbers at the end of the logcat that are in the range of the numbers allocated early in the log (gradually increasing numbers being a sure sign of a leak); also, a manual check over multiple cycles shows that we're not leaking any blocks either.

Comment 9

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

(In reply to Kan-Ru Chen [:kanru] from comment #2)
>
> I/Gecko   ( 1041): [Child 1041] ###!!! ABORT: [PImageContainerChild]
> abort()ing as a result: file PImageContainerChild.cpp, line 527

I saw this type of error *once* before, but when I rebuilt, it never appeared again.

Comment 10

[Dietrich Ayala (:dietrich)]

Hi Kanru and Mike, is there an ETA for fixing this? Do you know the approach to fix yet?

Comment 11

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

I haven't been able to reproduce this issue, and have been working on other bugs: the gecko-18 branch is a little flaky these days.  If you don't have time, kanru, I can dig into this tomorrow.

Comment 12

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

gecko-18 is what we're shipping.  "A little flaky" isn't acceptable, we need names, bug #'s, commit IDs.  You should do primary dev on gecko-18.

Comment 13

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

I seem to have discovered good STR in bug 822917.

Comment 15

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

The crash is occurring because of a loss of sync between the camera app in Gaia and the CameraControl object in Gecko.

When the camera app is hidden and then brought to the foreground again, the Camera.startPreview() method calls Camera.setSource(), which passes in a camera ID (e.g. front or back) but not a mode; setSource() creates a new CameraControl object, which by default comes up in picture mode, but the app UI will be in the mode it was previously in when hidden--either picture or video mode.  When the shutter/record button is pressed, the camera calls startRecording(), which in the new CameraControl object access a null pointer.  Bad.

The solution to the crash is to check for the null pointer and fail out early with an error.

:dale, the fix for the overall experience is for Camera.setSource.gotCamera() to call either getPreviewStream() or getPreviewStreamVideoMode() based on Camera.captureMode (either CAMERA or VIDEO).

Comment 16

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

Attachment: Make sure we have a recorder object before starting recording

This fix causes startRecording() to return an error if getPreviewStreamVideoMode() was not called first.

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I ran into a similar crash where I create a video, then switched to the video app, played the video in the video app, went back to the camera and to record another video and crashed.

Waiting for this to land in the product to see if it gets fixed with this patch.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8099630f363d

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8099630f363d

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e1436d4f4d22
https://hg.mozilla.org/releases/mozilla-b2g18/rev/4d8b531f30f5