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)
Tracking
(blocking-b2g:leo+, 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.
Comment 1•11 years ago
|
||
Due to crashing on camera app and impact on smoketest test cases, request escalation to PR1
blocking-b2g: --- → leo?
Comment 2•11 years ago
|
||
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]
Comment 3•11 years ago
|
||
I can confirm that this occurs on Hamachi as well. Investigating.
status-b2g18:
--- → affected
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
Comment 4•11 years ago
|
||
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
Updated•11 years ago
|
Assignee: nobody → mhabicher
Comment 5•11 years ago
|
||
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)
Comment 6•11 years ago
|
||
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)
Assignee | ||
Comment 7•11 years ago
|
||
It's entirely possible that this is related to the device storage work. I'll take a look.
Flags: needinfo?(dhylands)
Updated•11 years ago
|
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
Assignee | ||
Comment 9•11 years ago
|
||
Assignee | ||
Updated•11 years ago
|
Attachment #750232 -
Flags: review?(mhabicher)
Comment 10•11 years ago
|
||
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+
Assignee | ||
Comment 11•11 years ago
|
||
(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.
Assignee | ||
Updated•11 years ago
|
Component: Gaia::Video → General
Assignee | ||
Comment 12•11 years ago
|
||
https://hg.mozilla.org/projects/birch/rev/77336d1d37f6
Whiteboard: [b2g-crash] → [b2g-crash][fixed-in-birch]
Comment 14•11 years ago
|
||
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.
Comment 15•11 years ago
|
||
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)
Comment 16•11 years ago
|
||
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)
Assignee | ||
Comment 17•11 years ago
|
||
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?
Assignee | ||
Comment 18•11 years ago
|
||
(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.
Comment 19•11 years ago
|
||
(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)
Comment 20•11 years ago
|
||
(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
Comment 21•11 years ago
|
||
(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.
Comment 22•11 years ago
|
||
(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.
Comment 23•11 years ago
|
||
(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.
Updated•11 years ago
|
Whiteboard: [b2g-crash][fixed-in-birch] → [b2g-crash][fixed-in-birch][inarirun2]
Comment 24•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/77336d1d37f6
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 25•11 years ago
|
||
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+
Assignee | ||
Updated•11 years ago
|
status-b2g18-v1.0.0:
--- → wontfix
status-b2g18-v1.0.1:
--- → wontfix
status-firefox21:
--- → wontfix
status-firefox22:
--- → wontfix
status-firefox23:
--- → wontfix
status-firefox24:
--- → fixed
Assignee | ||
Updated•11 years ago
|
tracking-b2g18:
? → ---
Reporter | ||
Comment 27•11 years ago
|
||
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.
Updated•11 years ago
|
Whiteboard: [b2g-crash][fixed-in-birch][inarirun2] → [b2g-crash][fixed-in-birch], inarirun2
Assignee | ||
Comment 28•11 years ago
|
||
I've been able to record video on my leo device (running master)
Comment 29•11 years ago
|
||
Verified Leo Buri and inari devises does not have this issue anymore.
Status: RESOLVED → VERIFIED
Updated•11 years ago
|
Flags: in-moztrap?
You need to log in
before you can comment on or make changes to this bug.
Description
•