Closed
Bug 820139
Opened 12 years ago
Closed 12 years ago
camera - crash when switching between camera and camcorder and in between recording videos
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)
People
(Reporter: ikumar, Assigned: mikeh)
References
Details
Attachments
(1 file, 1 obsolete file)
6.94 KB,
patch
|
kanru
:
review+
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
I can't reproduce this on m-c + unagi. I'll try my dogfood phone.
Comment 2•12 years ago
|
||
I/Gecko ( 1041): [Child 1041] ###!!! ABORT: [PImageContainerChild] abort()ing as a result: file PImageContainerChild.cpp, line 527
Comment 3•12 years ago
|
||
I can crash it with just two switch. It doesn't seem to leak pmem.
Comment 4•12 years ago
|
||
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 ?? ()
Updated•12 years ago
|
Assignee: nobody → kchen
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C3 (12dec-1jan)
Comment 5•12 years ago
|
||
This is very hard to reproduce on m-c :(
Comment 6•12 years ago
|
||
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?)
Assignee | ||
Comment 7•12 years ago
|
||
(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.
Assignee | ||
Comment 8•12 years ago
|
||
(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.
Assignee | ||
Comment 9•12 years ago
|
||
(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•12 years ago
|
||
Hi Kanru and Mike, is there an ETA for fixing this? Do you know the approach to fix yet?
Assignee | ||
Comment 11•12 years ago
|
||
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.
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.
Assignee | ||
Comment 13•12 years ago
|
||
I seem to have discovered good STR in bug 822917.
Assignee | ||
Updated•12 years ago
|
Assignee: kchen → mhabicher
Assignee | ||
Comment 15•12 years ago
|
||
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).
Assignee | ||
Comment 16•12 years ago
|
||
This fix causes startRecording() to return an error if getPreviewStreamVideoMode() was not called first.
Attachment #690556 -
Attachment is obsolete: true
Attachment #694095 -
Flags: review?(kchen)
Assignee | ||
Updated•12 years ago
|
Status: NEW → ASSIGNED
Updated•12 years ago
|
Attachment #694095 -
Flags: review?(kchen) → review+
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
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.
Updated•12 years ago
|
Whiteboard: [has patch, has review, needs landing]
Comment 18•12 years ago
|
||
Keywords: checkin-needed
Whiteboard: [has patch, has review, needs landing]
Comment 19•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 20•12 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•