Closed Bug 872170 Opened 11 years ago Closed 11 years ago

[B2G] [Leo][Hamachi] [Inari] [Camera] Attempting to make a video recording causes the camera to crash

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

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

VERIFIED FIXED
blocking-b2g leo+
Tracking Status
firefox21 --- wontfix
firefox22 --- wontfix
firefox23 --- wontfix
firefox24 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- wontfix

People

(Reporter: ckreinbring, Assigned: dhylands)

References

()

Details

(Keywords: crash, regression, smoketest, Whiteboard: [b2g-crash][fixed-in-birch], inarirun2)

Crash Data

Attachments

(3 files)

Description:
If the user attempts to make a video recording, the Camera app will crash.

Repro Steps:
1) Updated to Leo Build ID: 20130514070207
2) Launch the Camera app.
3) If not already enabled, tap the video camera icon in the lower right corner to enable video mode.
4) Tap the highlighted video camera icon to start video recording.
5) Observe the device's reaction.

Actual:
The camera app crashes.

Expected:
Video recording begins with no errors.

Environmental Variables:
Occurs on the Leo 1.1 mozilla RIL
Build ID: 20130514070207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/58e5ff2fcfce
Gaia: 9841cfc141e3f849aba780592e02a482b17eb570
Version #: 18.0

Notes:
Repro frequency: 100%
Test Suite Name: Firefox OS Daily Smoketest
UCID: Daily smoketest
Link to failed test case: https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=2477
Q Analysts Test Team Priority: Pri 1
See attached Logcat logs for more info.
Due to crashing on camera app and impact on smoketest test cases, request escalation to PR1
blocking-b2g: --- → leo?
Crash ID: bp-602f884b-96fc-4158-86d1-44c642130514
Severity: normal → critical
Crash Signature: https://crash-stats.mozilla.com/report/index/602f884b-96fc-4158-86d1-44c642130514 → [@ mozilla::CameraControlImpl::StartRecording]
Keywords: crash
Whiteboard: [b2g-crash]
I can confirm that this occurs on Hamachi as well.  Investigating.
tracking-b2g18: --- → ?
Keywords: regression
Summary: [B2G] [Leo] [Camera] Attempting to make a video recording causes the camera to crash → [B2G] [Leo][Hamachi] [Camera] Attempting to make a video recording causes the camera to crash
This includes camera debugging output (produced with B2G_DEBUG=1 and |export NSPR_LOG_MODULES=Camera:4| set on the DUT).

It's not obvious from the context what's happening:

D(  133:0xf9) Layer buffer rotated 90 degrees
D(  133:0xf9) Frame rendered
I(  516:0x206) 357976[4557fe80]: queueBuffer: E
I(  516:0x206) 357976[4557fe80]: GonkNativeWindow::getCurrentBuffer
I(  516:0x206) 357976[4557fe80]: android::CameraGraphicBuffer::CameraGraphicBuffer(android::GonkNativeWindow*, uint32_t, uint32_t, mozilla::layers::SurfaceDescriptor):316 : this=444e3640
I(  516:0x206) 357976[4557fe80]: bool mozilla::DOMCameraPreview::ReceiveFrame(void*, mozilla::ImageFormat, void (*)(mozilla::layers::Image*, void*, uint32_t, uint32_t)):180 : this=4549d760
I(  516:0x206) 357976[4557fe80]: queueBuffer: X
I(  516:0x20f) 370672[444c9430]: GonkNativeWindow::returnBuffer: slot=1 (generation=2)
I(  516:0x20f) 370672[444c9430]: virtual android::CameraGraphicBuffer::~CameraGraphicBuffer():321 : this=444e3180
I(  516:0x225) 382080[455c6350]: dequeueBuffer: E
I(  516:0x225) 382080[455c6350]: dequeueBuffer: returning slot=0 buf=455903d0 
I(  516:0x225) 382080[455c6350]: dequeueBuffer: returning slot=0 buf=455903d0 
I(  516:0x225) 382080[455c6350]: dequeueBuffer: X
D(  133:0xf9) Layer buffer rotated 90 degrees
D(  133:0xf9) Frame rendered
E(  163:0x214) vfe_aecawb_stats_update: 
E(  163:0x214) vfe_aecawb_stats_update: AWB_AEC stats not enabled
F(  516:0x204) Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
E(  133:0x10a) VirtualSensor:set accel for virtual sensor!
E(  133:0x10a) VirtualSensor: readEvents start!!!count=15,mPendingMask=4
E(  133:0x10a) VirtualSensor: submit event:47d90660
I(  516:0x208) 365696[4557fd30]: queueBuffer: E
I(  516:0x208) 365696[4557fd30]: GonkNativeWindow::getCurrentBuffer
I(  516:0x208) 365696[4557fd30]: android::CameraGraphicBuffer::CameraGraphicBuffer(android::GonkNativeWindow*, uint32_t, uint32_t, mozilla::layers::SurfaceDescriptor):316 : this=444e3180
I(  516:0x208) 365696[4557fd30]: bool mozilla::DOMCameraPreview::ReceiveFrame(void*, mozilla::ImageFormat, void (*)(mozilla::layers::Image*, void*, uint32_t, uint32_t)):180 : this=4549d760
I(  516:0x208) 365696[4557fd30]: queueBuffer: X
I(  516:0x206) 357976[4557fe80]: dequeueBuffer: E
I(  516:0x206) 357976[4557fe80]: dequeueBuffer: returning slot=1 buf=45590380 
I(  516:0x206) 357976[4557fe80]: dequeueBuffer: returning slot=1 buf=45590380 
I(  516:0x206) 357976[4557fe80]: dequeueBuffer: X
D(  133:0xf9) Layer buffer rotated 90 degrees
I(  516:0x20f) 370672[444c9430]: GonkNativeWindow::returnBuffer: slot=2 (generation=2)
I(  516:0x20f) 370672[444c9430]: virtual android::CameraGraphicBuffer::~CameraGraphicBuffer():321 : this=444e3640
D(  133:0xf9) Frame rendered

The debuggerd output doesn't show anything obvious either:

I(  138:0x8a) Build fingerprint: 'unknown'
I(  138:0x8a) pid: 516, tid: 516  >>> /system/b2g/plugin-container <<<
I(  138:0x8a) signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I(  138:0x8a)  r0 44e2f240  r1 00000000  r2 00000000  r3 425ebac0
I(  138:0x8a)  r4 beea8980  r5 00000000  r6 44efcb80  r7 beea8918
I(  138:0x8a)  r8 40a0c195  r9 425ebac0  10 beea8934  fp beea89b4
I(  138:0x8a)  ip 40128824  sp beea8910  lr 40bac673  pc 40bb03ec  cpsr 60000030
I(  138:0x8a)  d0  5a5a5a5a5a5a5a5a  d1  5a5a5a5a5a5a5a5a
I(  138:0x8a)  d2  5a5a5a5a5a5a5a5a  d3  5a5a5a5a5a5a5a5a
I(  138:0x8a)  d4  0000000600000000  d5  0069007600000000
I(  138:0x8a)  d6  3f80000000650064  d7  7ade00003f537a6f
I(  138:0x8a)  d8  ffffff8200000000  d9  0000000000000000
I(  138:0x8a)  d10 0000000000000000  d11 0000000000000000
I(  138:0x8a)  d12 0000000000000000  d13 0000000000000000
I(  138:0x8a)  d14 0000000000000000  d15 0000000000000000
I(  138:0x8a)  d16 0000000000000000  d17 41deb78000000000
I(  138:0x8a)  d18 42b8000000000000  d19 3ff0000000000000
I(  138:0x8a)  d20 0000000000000000  d21 005a004d00300030
I(  138:0x8a)  d22 002f0041004c004c  d23 004400490056002e
I(  138:0x8a)  d24 3ff0000000000000  d25 0000000000000000
I(  138:0x8a)  d26 0000000000000000  d27 0000000000000000
I(  138:0x8a)  d28 cc0000002d2d2d2d  d29 cc000000cc000000
I(  138:0x8a)  d30 0000010101010101  d31 ccccf1ffd9d9d9d9
I(  138:0x8a)  scr 68000011
 ...
I(  138:0x8a)          #00  pc 0079f3ec  /system/b2g/libxul.so
I(  138:0x8a)          #01  lr 40bac673  /system/b2g/libxul.so
I(  138:0x8a) 
I(  138:0x8a) code around pc:
I(  138:0x8a) 40bb03cc 013499d6 4ff0e92d 8b02ed2d af02b08b  ..4.-..O-.......
I(  138:0x8a) 40bb03dc 0a20f107 4699460c f84a2100 46151d04  .. ..F.F.!J....F
I(  138:0x8a) 40bb03ec 46806813 6d3e4650 b0acf8d3 f204f466  .h.FPF>m....f...
I(  138:0x8a) 40bb03fc 46284651 69f947d8 4650b111 f2f6f470  QF(F.G.i..PFp...
I(  138:0x8a) 40bb040c 001cf107 f467463d cc0ff0f3 6823c50f  ....=Fg.......#h
I(  138:0x8a) 
I(  138:0x8a) code around lr:
I(  138:0x8a) 40bac650 f7ff0568 f8d7f8d3 f1072090 68030110  h........ .....h
I(  138:0x8a) 40bac660 f8d79200 92012094 f855695c 68bb2d0c  ..... ..\iU..-.h
I(  138:0x8a) 40bac670 460447a0 f46a4628 f107f019 f46a0064  .G.F(Fj.....d.j.
I(  138:0x8a) 40bac680 f107f015 f4740010 4620f1b7 076cf107  ......t... F..l.
I(  138:0x8a) 40bac690 e8bd46bd bf008ff0 80070057 80004005  .F......W....@..
I(  138:0x8a) 
I(  138:0x8a) stack:
I(  138:0x8a)     beea88d0  beea88f0  [stack]
I(  138:0x8a)     beea88d4  45591640  
I(  138:0x8a)     beea88d8  00000000  
I(  138:0x8a)     beea88dc  425e8818  
I(  138:0x8a)     beea88e0  beea89b4  [stack]
I(  138:0x8a)     beea88e4  00000001  
I(  138:0x8a)     beea88e8  00090059  
I(  138:0x8a)     beea88ec  444e35a4  
I(  138:0x8a)     beea88f0  00000001  
I(  138:0x8a)     beea88f4  0009005f  
I(  138:0x8a)     beea88f8  45591640  
I(  138:0x8a)     beea88fc  beea8910  [stack]
I(  138:0x8a)     beea8900  00000000  
I(  138:0x8a)     beea8904  00000000  
I(  138:0x8a)     beea8908  df0027ad  
I(  138:0x8a)     beea890c  00000000  
I(  138:0x8a) #00 beea8910  45561700  
I(  138:0x8a)     beea8914  00000000  
I(  138:0x8a)     beea8918  beea8930  [stack]
I(  138:0x8a)     beea891c  beea89c0  [stack]
I(  138:0x8a)     beea8920  00000000  
I(  138:0x8a)     beea8924  40a5eb3f  /system/b2g/libxul.so
I(  138:0x8a)     beea8928  beea893f  [stack]
I(  138:0x8a)     beea892c  40a5eadd  /system/b2g/libxul.so
I(  138:0x8a)     beea8930  00000000  
I(  138:0x8a)     beea8934  00000000  
I(  138:0x8a)     beea8938  454f1ba0  
I(  138:0x8a)     beea893c  00000000  
I(  138:0x8a)     beea8940  ffffff82  
I(  138:0x8a)     beea8944  40bb03d1  /system/b2g/libxul.so
I(  138:0x8a)     beea8948  beea89cc  [stack]
I(  138:0x8a)     beea894c  44efcb80  
I(  138:0x8a)     beea8950  beea8970  [stack]
I(  138:0x8a)     beea8954  40a0c195  /system/b2g/libxul.so
Assignee: nobody → mhabicher
gdb bt:

Program received signal SIGSEGV, Segmentation fault.
mozilla::CameraControlImpl::StartRecording (this=0x44c19240, aOptions=0xbe8059b0, aFolder=0x0, 
    aFilename=..., onSuccess=0x448c0600, onError=0x448c0620)
    at /home/mikeh/dev/mozilla/m-c/b2g18/dom/camera/CameraControlImpl.cpp:380
380	  aFolder->Clone(getter_AddRefs(clone));

#0  mozilla::CameraControlImpl::StartRecording (this=0x44c19240, aOptions=0xbe8059b0, aFolder=0x0, 
    aFilename=..., onSuccess=0x448c0600, onError=0x448c0620)
    at /home/mikeh/dev/mozilla/m-c/b2g18/dom/camera/CameraControlImpl.cpp:380
#1  0x40c0f672 in mozilla::nsDOMCameraControl::StartRecording (this=<value optimized out>, 
    aOptions=<value optimized out>, storageArea=0x44cd4b20, filename=<value optimized out>, 
    onSuccess=0x448c0600, onError=0x448c0620, cx=0x42481a70)
    at /home/mikeh/dev/mozilla/m-c/b2g18/dom/camera/DOMCameraControl.cpp:293
#2  0x412302fa in NS_InvokeByIndex_P (that=0x44c88720, methodIndex=35, paramCount=<value optimized out>, 
    params=<value optimized out>)
    at /home/mikeh/dev/mozilla/m-c/b2g18/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:160
#3  0x40d827f8 in CallMethodHelper::Invoke (this=0xbe805d50)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/xpconnect/src/XPCWrappedNative.cpp:3084
#4  CallMethodHelper::Call (this=0xbe805d50)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/xpconnect/src/XPCWrappedNative.cpp:2418
#5  0x40d83a54 in XPCWrappedNative::CallMethod (ccx=..., mode=<value optimized out>)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/xpconnect/src/XPCWrappedNative.cpp:2384
#6  0x40d8ac32 in XPC_WN_CallMethod (cx=0x42481a70, argc=5, vp=<value optimized out>)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1469
#7  0x4153ec5c in js::CallJSNative (cx=0x42481a70, 
    native=0x40d8ab7d <XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)>, args=...)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jscntxtinlines.h:364
#8  0x41552eac in js::InvokeKernel (cx=0x42481a70, args=..., construct=js::NO_CONSTRUCT)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:367
#9  0x4154c216 in js::Interpret (cx=0x42481a70, entryFrame=<value optimized out>, 
    interpMode=<value optimized out>) at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:2475
#10 0x4155276c in js::RunScript (cx=0x42481a70, script=<value optimized out>, fp=0x438000a8)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:324
#11 0x41552f2c in js::InvokeKernel (cx=0x42481a70, args=..., construct=js::NO_CONSTRUCT)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:378
#12 0x41500f0e in Invoke (cx=<value optimized out>, argc=<value optimized out>, vp=<value optimized out>)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.h:109
#13 js::CallOrConstructBoundFunction (cx=<value optimized out>, argc=<value optimized out>, 
    vp=<value optimized out>) at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsfun.cpp:1095
#14 0x4153ec5c in js::CallJSNative (cx=0x42481a70, 
    native=0x41500c7d <js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*)>, args=...)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jscntxtinlines.h:364
#15 0x41552eac in js::InvokeKernel (cx=0x42481a70, args=..., construct=js::NO_CONSTRUCT)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:367
#16 0x4154c216 in js::Interpret (cx=0x42481a70, entryFrame=<value optimized out>, 
    interpMode=<value optimized out>) at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:2475
#17 0x4155276c in js::RunScript (cx=0x42481a70, script=<value optimized out>, fp=0x43800038)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:324
#18 0x41552f2c in js::InvokeKernel (cx=0x42481a70, args=..., construct=js::NO_CONSTRUCT)
    at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:378
#19 0x41553724 in Invoke (cx=0x42481a70, thisv=..., fval=..., argc=<value optimized out>, 
    argv=0xbe806d98, rval=0xbe806e60) at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.h:109
#20 js::Invoke (cx=0x42481a70, thisv=..., fval=..., argc=<value optimized out>, argv=0xbe806d98, 
    rval=0xbe806e60) at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsinterp.cpp:411
#21 0x41490c02 in JS_CallFunctionValue (cx=0x42481a70, objArg=0x44376e00, fval=..., argc=1, 
    argv=0xbe806d98, rval=0xbe806e60) at /home/mikeh/dev/mozilla/m-c/b2g18/js/src/jsapi.cpp:5893
#22 0x40a002de in nsJSContext::CallEventHandler (this=0x42448380, aTarget=<value optimized out>, 
    aScope=<value optimized out>, aHandler=<value optimized out>, aargv=0x4483caa0, arv=0xbe806fc0)
    at /home/mikeh/dev/mozilla/m-c/b2g18/dom/base/nsJSEnvironment.cpp:1954
#23 0x40aa6d10 in nsJSEventListener::HandleEvent (this=0x4486b5e0, aEvent=0x444c4ac0)
    at /home/mikeh/dev/mozilla/m-c/b2g18/dom/src/events/nsJSEventListener.cpp:215
#24 0x408d134e in nsEventListenerManager::HandleEventSubType (this=<value optimized out>, 
    aListenerStruct=<value optimized out>, aListener=0x4486b5e0, aDOMEvent=0x444c4ac0, 
    aCurrentTarget=0x4448c540, aPhaseFlags=6, aPusher=0xbe807178)
Context for the offending line:
https://mxr.mozilla.org/mozilla-b2g18/source/dom/camera/CameraControlImpl.cpp#380

This is called from here (where the 'aFolder' parameter is set):
https://mxr.mozilla.org/mozilla-b2g18/source/dom/camera/DOMCameraControl.cpp#292

Neither of these sections have changed recently.  dhylands, could this be related to the recent work on device storage?

I may put a guard in ::StartRecording() to make sure 'aFolder' is !nullptr.
Flags: needinfo?(dhylands)
It's entirely possible that this is related to the device storage work. I'll take a look.
Flags: needinfo?(dhylands)
Sweet, thanks!
Assignee: mhabicher → dhylands
Summary: [B2G] [Leo][Hamachi] [Camera] Attempting to make a video recording causes the camera to crash → [B2G] [Leo][Hamachi] [Inari] [Camera] Attempting to make a video recording causes the camera to crash
Attachment #750232 - Flags: review?(mhabicher)
Comment on attachment 750232 [details] [diff] [review]
Fix camera file saving with composite device storage.

Review of attachment 750232 [details] [diff] [review]:
-----------------------------------------------------------------

r+ provided the relative pathnames provided by the camera app are okay.

::: dom/devicestorage/nsDeviceStorage.cpp
@@ +2942,5 @@
> +  nsRefPtr<nsDOMDeviceStorage> ds;
> +
> +  if (IsComposite()) {
> +    nsString storagePath;
> +    ds = GetStorage(aName, storagePath);

Is this okay with handling filenames that include relative paths? e.g. "DCIM/vid_0003.3gp"?
Attachment #750232 - Flags: review?(mhabicher) → review+
(In reply to Mike Habicher [:mikeh] from comment #10)
> Comment on attachment 750232 [details] [diff] [review]
> Fix camera file saving with composite device storage.
> 
> Review of attachment 750232 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r+ provided the relative pathnames provided by the camera app are okay.
> 
> ::: dom/devicestorage/nsDeviceStorage.cpp
> @@ +2942,5 @@
> > +  nsRefPtr<nsDOMDeviceStorage> ds;
> > +
> > +  if (IsComposite()) {
> > +    nsString storagePath;
> > +    ds = GetStorage(aName, storagePath);
> 
> Is this okay with handling filenames that include relative paths? e.g.
> "DCIM/vid_0003.3gp"?

Yep. GetStorage will take both fully qualified names /storageName/filename, or relative ones. For the relative ones, it will look at the user preference for where new files should be stored, and return that storage area.

Which reminds me, I need to file another bug to have mediadb persist the fully qualified names.
Component: Gaia::Video → General
https://hg.mozilla.org/projects/birch/rev/77336d1d37f6
Whiteboard: [b2g-crash] → [b2g-crash][fixed-in-birch]
I was trying to figure this bug out from a Gaia perspective in bug 873178.  Here is what I found before Mike pointed me to this one.

In apps/camera/js/camera.js, in the startRecording() function, we use addNamed() to create a dummy file and then delete that file. We do this to ensure that the directory we want exists before passing the path to the camera.

I found that addNamed() was working okay to create the dummy file, and would prepend "/sdcard/" to the name I specified.

Then, when the relative name was passed to delete(), I was getting a crash there.

Changing the gaia code to use the fully-qualified name fixed that crash.

But then, I got another crash when passing the unqualified name to the camera object's startRecording() function.  I haven't tested yet whether passing a fully-qualified name there fixes it.
Mike,

How does the camera hardware want the filename specified?

Currently the camera app has this code:

      this._cameraObj.startRecording(config,
                                     this._videoStorage, this._videoPath,
                                     onsuccess, onerror);

where _videoStorage is the device storage object and _videoPath is the relative path. Do you need the app to change to make that into an absolute path?  Or is the camera hardware using the device storage object to resolve it? Or is the camera querying the same setting that device storage does to determine the default?

If the camera is now talking to the device storage object to convert a relative path to a fully-qualfied one, does the camera app still have to create and delete a dummy file to create a directory, or is that no longer necessary?
Flags: needinfo?(mhabicher)
Changing to a fully-qualified path in gaia does not prevent the crash. I still get a crash when calling this._cameraObj.startRecording(). (That's probably already obvious to Mike and Dave from their diagnosis above)
I'll interject some comments.

(In reply to David Flanagan [:djf] from comment #15)
> Mike,
> 
> How does the camera hardware want the filename specified?
> 
> Currently the camera app has this code:
> 
>       this._cameraObj.startRecording(config,
>                                      this._videoStorage, this._videoPath,
>                                      onsuccess, onerror);
> 
> where _videoStorage is the device storage object and _videoPath is the
> relative path. Do you need the app to change to make that into an absolute
> path?  Or is the camera hardware using the device storage object to resolve
> it? Or is the camera querying the same setting that device storage does to
> determine the default?

I think that mediaDB or the app should specify a fully qualified name (fully qualified in the device storage sense). I'm guessing that you still need to create and delete the dummy file to cause the directory to be created. it would be useful to have a comment in the code to indicate that's what's happening. I saw the code and I thought it was just checking to make sure it was writable or something.

So, for example, when it calls addNamed to create the dummy file, the onsucess can get the fully qualified name;

function onsuccess(e) {
  var filename = e.target.result;
}

If you passed in DCIM/foo.jpg to addNamed, you'd get back something like /sdcard/DCIM/foo.jpg or /extsdcard/DCIM/foo.jpg

With the changes provided in the patch attached to this bug, it will accept either form of the name.

> If the camera is now talking to the device storage object to convert a
> relative path to a fully-qualfied one, does the camera app still have to
> create and delete a dummy file to create a directory, or is that no longer
> necessary?

I think its still required. device storage doesn't have any explicit API to cause the directory to be created, other than as a side-effect of calling addNamed.

Although, if it requies the file to not exist, why not just add and remove the real name rather than adding and removing a dummy name?
(In reply to David Flanagan [:djf] from comment #16)
> Changing to a fully-qualified path in gaia does not prevent the crash. I
> still get a crash when calling this._cameraObj.startRecording(). (That's
> probably already obvious to Mike and Dave from their diagnosis above)

Yeah - the problem was that the composite storage object has a null mRootDirectory, regardless of the path being passed in.

The code was then just trying to dereference that null mRootDirectory which is what caused the crash. The call to GetStorage (in the patch) converts the composite device storage object into a real storage object, which has a real mRootDirectory.
(In reply to Dave Hylands [:dhylands] from comment #18)
> 
> Yeah - the problem was that the composite storage object has a null
> mRootDirectory, regardless of the path being passed in.

I think it might be worth putting a null-check in there to catch this in the future.
Flags: needinfo?(mhabicher)
(In reply to David Flanagan [:djf] from comment #15)
>
> Mike, how does the camera hardware want the filename specified?

Dave, the camera takes the _videoStorage part, gets the root folder for it, appends _videoPath to it, and then passes the resulting string to open().

You can see the guts here: http://mxr.mozilla.org/mozilla-central/source/dom/camera/GonkCameraControl.cpp#895
(In reply to Mike Habicher [:mikeh] from comment #20)
> (In reply to David Flanagan [:djf] from comment #15)
> >
> > Mike, how does the camera hardware want the filename specified?
> 
> Dave, the camera takes the _videoStorage part, gets the root folder for it,
> appends _videoPath to it, and then passes the resulting string to open().
> 
> You can see the guts here:
> http://mxr.mozilla.org/mozilla-central/source/dom/camera/GonkCameraControl.
> cpp#895

So basically, your camera code is already aware of Dave's DeviceStorage changes, and it would break things if the Camera app were to try to fully-qualify the path in advance.
(In reply to Dave Hylands [:dhylands] from comment #17)
> Although, if it requies the file to not exist, why not just add and remove
> the real name rather than adding and removing a dummy name?

If I use the real name, then the Video app thinks there is a new video to scan. The dummy filename has a leading . which makes MediaDB ignore it.

Its a complete hack to work around the camera hardware just calling open() without checking that directories exist.
(In reply to David Flanagan [:djf] from comment #21)
> 
> So basically, your camera code is already aware of Dave's DeviceStorage
> changes, and it would break things if the Camera app were to try to
> fully-qualify the path in advance.

That's correct.
Whiteboard: [b2g-crash][fixed-in-birch] → [b2g-crash][fixed-in-birch][inarirun2]
https://hg.mozilla.org/mozilla-central/rev/77336d1d37f6
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
I marked this as leo+ since without this patch, trying to record video crashes.

https://hg.mozilla.org/releases/mozilla-b2g18/rev/8b45f1643d74
Blocks: 858416
blocking-b2g: leo? → leo+
tracking-b2g18: ? → ---
See Also: → 873971
Depends on: 874615
Fix verified on the Inari and Hamachi devices.  Tested on 1.1 mozilla and commercial RIL.  The user is able to start recording video when the video camera icon is selected.

Currently unable to verify on the Leo due to defect 874615.
Whiteboard: [b2g-crash][fixed-in-birch][inarirun2] → [b2g-crash][fixed-in-birch], inarirun2
I've been able to record video on my leo device (running master)
Verified Leo Buri and inari devises does not have this issue anymore.
Status: RESOLVED → VERIFIED
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap+
QA Contact: amiller
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: