Created attachment 690556 [details] 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.
I can't reproduce this on m-c + unagi. I'll try my dogfood phone.
I/Gecko ( 1041): [Child 1041] ###!!! ABORT: [PImageContainerChild] abort()ing as a result: file PImageContainerChild.cpp, line 527
I can crash it with just two switch. It doesn't seem to leak pmem.
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 ?? ()
Assignee: nobody → kchen
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C3 (12dec-1jan)
This is very hard to reproduce on m-c :(
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?)
(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.
(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.
(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.
Hi Kanru and Mike, is there an ETA for fixing this? Do you know the approach to fix yet?
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.
I seem to have discovered good STR in bug 822917.
Assignee: kchen → mhabicher
Duplicate of this bug: 822917
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).
Created attachment 694095 [details] [diff] [review] Make sure we have a recorder object before starting recording This fix causes startRecording() to return an error if getPreviewStreamVideoMode() was not called first.
Status: NEW → ASSIGNED
Attachment #694095 - Flags: review?(kchen) → review+
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.
Whiteboard: [has patch, has review, needs landing]
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
status-b2g18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed
Duplicate of this bug: 823956
You need to log in before you can comment on or make changes to this bug.