Closed Bug 862256 Opened 8 years ago Closed 8 years ago

Crash seen in CameraControlImpl while on call and taking pictures


(Firefox OS Graveyard :: General, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:tef+, firefox21 wontfix, firefox22 wontfix, firefox23 fixed, b2g18+ verified, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

blocking-b2g tef+
Tracking Status
firefox21 --- wontfix
firefox22 --- wontfix
firefox23 --- fixed
b2g18 + verified
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- verified


(Reporter: ggrisco, Assigned: mikeh)


(Keywords: crash, Whiteboard: [b2g-crash][CR 475959][fixed-in-birch])

Crash Data


(1 file, 2 obsolete files)

Attached file decoded minidump of crash (obsolete) —
1. Go to and open the game “animalconnect.”( slide to left from the home screen)
2. Taking time to open, loading screen is displayed.
3. Make a MO (mobile originated) call and answer the call on third party side.
4. When call is in progress, open camera and take pictures.
5. While taking pictures, at the bottom, “Below one icon bar displayed to refresh the page, sync kind”.
6. That icon bar is overlapped with the camera capture button and camcorder buttons place.
7. Still tapped on the camera capture button to take pictures.
8. Camera just crashed message displayed.

Reproducibility: Seen once
blocking-b2g: --- → leo?
(leo+, detected during stability test)
blocking-b2g: leo? → leo+
Attached file EXTRA file attachment (obsolete) —
Thread 0 (crashed)
 0!jemalloc_crash [jemalloc.c : 1582 + 0x0]
 1!arena_dalloc [jemalloc.c : 3336 + 0x3]
 2!free [jemalloc.c : 6589 + 0x3]
 3!moz_free [mozalloc.cpp : 48 + 0x3]
 4!mozilla::CameraControlImpl::~CameraControlImpl [mozalloc.h : 224 + 0x5]
 5!mozilla::ICameraControl::Release [ICameraControl.h : 24 + 0x9]
 6!nsRunnableMethodImpl<void (mozilla::CameraControlImpl::*)(), true>::~nsRunnableMethodImpl [nsThreadUtils.h : 321 + 0x3]
 7!nsRunnableMethodImpl<void (mozilla::CameraControlImpl::*)(), true>::~nsRunnableMethodImpl [nsThreadUtils.h : 352 + 0x5]
 8!PipUIContext::Release [nsNSSComponent.cpp : 3050 + 0x7]
 9!mozilla::dom::AudioNode::Input::~Input + 0xd

...why is AudioNode::Input's destructor releasing the camera??
(I'm guessing this is a double-free, since ~CameraControlImpl() contains nothing in normal builds, and a single log statement in DEBUG builds.)
Crash Signature: [@ jemalloc_crash | arena_dalloc | free | moz_free | mozilla::CameraControlImpl::~CameraControlImpl]
Keywords: crash
Whiteboard: [CR 475959] → [b2g-crash][CR 475959]
I can reproduce this bug and make it crash in gdb. Here are the backtrace:

> Program received signal SIGSEGV, Segmentation fault.
> nsMainThreadPtrHolder<nsICameraErrorCallback>::get (this=<value optimized out>) at ../../dist/include/nsProxyRelease.h:135
> 135         return mRawPtr;
> (gdb) bt
> #0  nsMainThreadPtrHolder<nsICameraErrorCallback>::get (this=<value optimized out>) at ../../dist/include/nsProxyRelease.h:135
> #1  nsMainThreadPtrHandle<nsICameraErrorCallback>::get (this=<value optimized out>) at ../../dist/include/nsProxyRelease.h:181
> #2  0x40b90e8c in mozilla::CameraControlImpl::OnClosedInternal (this=<value optimized out>) at dom/camera/CameraControlImpl.cpp:279
> #3  0x404342b6 in nsRunnableMethodImpl<void (nsPACMan::*)(), true>::Run (this=<value optimized out>) at ../../../dist/include/nsThreadUtils.h:366
> #4  0x41187fb6 in nsThread::ProcessNextEvent (this=0x42407240, mayWait=<value optimized out>, result=0xbee37dd7) at xpcom/threads/nsThread.cpp:620
> #5  0x4114f7e0 in NS_ProcessNextEvent_P (thread=0x1, mayWait=false) at objdir-gecko-b2g18/xpcom/build/nsThreadUtils.cpp:237
> #6  0x40fc83d2 in mozilla::ipc::MessagePump::Run (this=0x42402340, aDelegate=0xbee388cc) at ipc/glue/MessagePump.cpp:82
> #7  0x40fc855a in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x42402340, aDelegate=0xbee388cc) at ipc/glue/MessagePump.cpp:231
> #8  0x411bddf2 in MessageLoop::RunInternal (this=0xbee388cc) at ipc/chromium/src/base/
> #9  0x411bde52 in MessageLoop::RunHandler (this=0xbee388cc) at ipc/chromium/src/base/
> #10 MessageLoop::Run (this=0xbee388cc) at ipc/chromium/src/base/
> #11 0x40f0386e in nsBaseAppShell::Run (this=0x4340b0a0) at widget/xpwidgets/nsBaseAppShell.cpp:163
> #12 0x4040a626 in XRE_RunAppShell () at toolkit/xre/nsEmbedFunctions.cpp:646
> #13 0x40fc84c4 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x42402340, aDelegate=0xbee388cc) at ipc/glue/MessagePump.cpp:198
> #14 0x411bddf2 in MessageLoop::RunInternal (this=0xbee388cc) at ipc/chromium/src/base/
> #15 0x411bde52 in MessageLoop::RunHandler (this=0xbee388cc) at ipc/chromium/src/base/
> #16 MessageLoop::Run (this=0xbee388cc) at ipc/chromium/src/base/
> #17 0x4040ae4c in XRE_InitChildProcess (aArgc=3, aArgv=0x42430800, aProcess=GeckoProcessType_Content) at toolkit/xre/nsEmbedFunctions.cpp:485
> #18 0x00008662 in main (argc=5, argv=0xbee38a44) at ipc/app/MozillaRuntimeMain.cpp:60
> (gdb) fr 2
> #2  0x40b90e8c in mozilla::CameraControlImpl::OnClosedInternal (this=<value optimized out>) at dom/camera/CameraControlImpl.cpp:279
> 279       if (mOnClosedCb.get()) {
> (gdb) p *this
> Cannot access memory at address 0x0

The stack is not the same as originally reported, but I think the root cause is the same: CameraControlImpl used after free.
The key here seems to be using the bottom navigation bar in the camera app (the bottom navigation bar is a gaia bug).
- Add some site to the home screen (e.g.
- Go back to the home screen and lauch the site using the icon and you will see the bottom navigation bar.
- While the site is still loading, quickly tap home button several times. You will see the navigaion bar still visible in the home screen if successful.
- Open the camera app. Interleave the usage of the camera app (take a picutre) and the navigation bar (refresh).
This certain messes up the UI, but as of yet I haven't been able to cause a crash with:
- gecko: b2g18:d1b2e28b303f (DEBUG)
- gaia: f8e8f2be6803b02d6a083b2a144a80e7ebf15951
Okay, I understand the problem here.  OnClosed() is being triggered in the CameraControl destructor, which is firing a runnable that called OnClosedInternal().  NS_DispatchToMainThread() holds a reference to 'this', but since 'this' is already being destroyed, the additional reference doesn't "save 'this'".

Then, at the end of OnClosedInternal(), the reference held by NS_DispatchToMainThread() is released and the CameraControl object is destroyed again.
Assignee: nobody → mhabicher
Cervantes/Greg, can you try out this patch?  I have tested it, and it should prevent the camera crash you're seeing.
Attachment #738496 - Flags: review?(sotaro.ikeda.g)
Attachment #738496 - Flags: feedback?(ggrisco)
Attachment #738496 - Flags: feedback?(cyu)
Attachment #738496 - Flags: review?(sotaro.ikeda.g) → review+
Comment on attachment 738496 [details] [diff] [review]
don't (re)reference dying or dead objects

Review of attachment 738496 [details] [diff] [review]:

I tried to reproduce with the patch applied and didn't see the crash. I think it's fixed.
Attachment #738496 - Flags: feedback?(cyu) → feedback+
Re-noming as tef? as since this was leo+ and affects 1.0.1, it should be tef+ too.
blocking-b2g: leo+ → tef?
blocking-b2g: tef? → tef+
Whiteboard: [b2g-crash][CR 475959] → [b2g-crash][CR 475959][fixed-in-birch]
Attachment #737870 - Attachment is obsolete: true
Attachment #737871 - Attachment is obsolete: true
Closed: 8 years ago
Resolution: --- → FIXED
Verified fixed on 

Inari Build ID: 20130430070201
Kernel Date: Feb 21
Gaia: de0f1fc6c58616b8a33fca482f1f8684d4e74e9e

and on 

Unagi Build ID: 20130430070204
Kernel Date: Dec 5
Gaia: b525c25063d33d2e073d9f3e1e1164fadefec998

Camera no longer crashes when following steps listed.
Attachment #738496 - Flags: feedback?(ggrisco)
You need to log in before you can comment on or make changes to this bug.