863290 - crash in webrtc::videocapturemodule::DeviceInfoAndroid::NumberOfDevices

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[Scoobidiver (away)]

There's one crash in 23.0a1/20130417.

Signature 	webrtc::videocapturemodule::DeviceInfoAndroid::NumberOfDevices() More Reports Search
UUID	a7ae40c2-684e-40d8-b5a9-56db92130418
Date Processed	2013-04-18 09:41:09
Uptime	156
Install Age	21.2 hours since version was first installed.
Install Time	2013-04-17 12:26:28
Product	FennecAndroid
Version	23.0a1
Build ID	20130417031053
Release Channel	nightly
OS	Android
OS Version	0.0.0 Linux 3.0.31-742798 #1 SMP PREEMPT Sat Dec 22 17:04:04 KST 2012 armv7l samsung/m0xx/m0:4.1.2/JZO54K/I9300XXELLA:user/release-keys
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x2c
App Notes 	
AdapterDescription: 'ARM -- Mali-400 MP -- OpenGL ES 2.0 -- Model: GT-I9300, Product: m0xx, Manufacturer: samsung, Hardware: smdk4x12'
GL Layers! EGL? EGL+ GL Context? GL Context+ GL Layers+ WebGL? WebGL+ Stagefright? Stagefright+ 
samsung GT-I9300
samsung/m0xx/m0:4.1.2/JZO54K/I9300XXELLA:user/release-keys
Processor Notes 	sp-processor05.phx1.mozilla.com_15317:2012; exploitability tool failed: 127
EMCheckCompatibility	True
Adapter Vendor ID	ARM
Adapter Device ID	Mali-400 MP
Device	samsung GT-I9300
Android API Version	16 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libdvm.so 	libdvm.so@0x4c948 	
1 	libdvm.so 	libdvm.so@0x4c92b 	
2 	libxul.so 	webrtc::videocapturemodule::DeviceInfoAndroid::NumberOfDevices 	jni.h:605
3 	libxul.so 	webrtc::ViEInputManager::CreateCaptureDevice 	vie_input_manager.cc:195
4 	binder 	binder@0x2a 	
5 	libbinder.so 	libbinder.so@0x1b6f9 	
6 	binder 	binder@0x26 	
7 	libbinder.so 	libbinder.so@0x1b6f9 	
8 	libbinder.so 	libbinder.so@0x15269 	
9 	libbinder.so 	libbinder.so@0x19c27 	
10 	libbinder.so 	libbinder.so@0x19c4b 	
11 	binder 	binder@0x26 	
12 	binder 	binder@0x26 	
13 	libbinder.so 	libbinder.so@0x19c91 	
14 	libbinder.so 	libbinder.so@0x171a3 	
15 	libbinder.so 	libbinder.so@0x16aaf 	
16 	libbinder.so 	libbinder.so@0x19f03 	
17 	binder 	binder@0x26 	
18 	binder 	binder@0x26 	
19 	libbinder.so 	libbinder.so@0x17305 	
20 	libbinder.so 	libbinder.so@0x19dfd 	
21 	libcamera_client.so 	libcamera_client.so@0x25a62 	
22 	libc.so 	libc.so@0x1c6a3 	
23 	libc.so 	libc.so@0x1c6a3 	
24 	libc.so 	libc.so@0x1c655 	
25 	libxul.so 	webrtc::CriticalSectionScoped::~CriticalSectionScoped 	critical_section_wrapper.h:52
26 	libxul.so 	webrtc::TraceImpl::AddMessageToList 	trace_impl.cc:463
27 	libxul.so 	webrtc::EventPosix::Wait 	event_posix.cc:157
28 	libxul.so 	webrtc::EventPosix::Set 	event_posix.cc:106
29 	libxul.so 	webrtc::TraceImpl::AddImpl 	trace_impl.cc:613
30 	dalvik-heap (deleted) 	dalvik-heap @0x256403f 	
31 	dalvik-heap (deleted) 	dalvik-heap @0x356461e 	
32 	dalvik-heap (deleted) 	dalvik-heap @0x2d2b35 	
33 	libxul.so 	libxul.so@0x6e4c6a 	
34 	dalvik-heap (deleted) 	dalvik-heap @0x272645f 	
35 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x125756f 	
36 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x2ca0467 	
37 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x1567961 	
38 	libc.so 	libc.so@0x1ee75 	
39 	libxul.so 	webrtc::CriticalSectionPosix::Leave 	critical_section_posix.cc:39
40 	libxul.so 	webrtc::CriticalSectionScoped::~CriticalSectionScoped 	critical_section_wrapper.h:52
41 	libxul.so 	webrtc::TraceImpl::StaticInstance 	static_instance.h:148
42 	libxul.so 	webrtc::Trace::Add 	trace_impl.cc:754
43 	OMXCodec (deleted) 	OMXCodec @0x2ee92e 	
44 	OMXCodec (deleted) 	OMXCodec @0x9b2c3f 	
45 	dalvik-heap (deleted) 	dalvik-heap @0x3726273 	
46 	libxul.so 	nsXBLWindowKeyHandler::WalkHandlersAndExecute 	nsXBLWindowKeyHandler.cpp:489
47 	OMXCodec (deleted) 	OMXCodec @0x52863 	
48 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x3d9095d 	
49 	OMXCodec (deleted) 	OMXCodec @0x11431e 	
50 	dalvik-heap (deleted) 	dalvik-heap @0x52d1c2f 	
51 	libxul.so 	webrtc::videocapturemodule::DeviceInfoImpl::GetCapability 	rw_lock_wrapper.h:43
52 	libxul.so 	webrtc::videocapturemodule::DeviceInfoImpl::GetBestMatchedCapability 	device_info_impl.cc:311
53 	libxul.so 	webrtc::ViEInputManager::GetCaptureCapability 	vie_input_manager.cc:111
54 	libxul.so 	webrtc::ViECaptureImpl::GetCaptureCapability 	vie_capture_impl.cc:472
55 	libxul.so 	webrtc::ViECaptureImpl::ShowCaptureSettingsDialogBox 	vie_capture_impl.cc:503
56 	libxul.so 	mozilla::MediaEngineWebRTCVideoSource::ChooseCapability 	MediaEngineWebRTCVideo.cpp:177
57 	libxul.so 	webrtc::ViECaptureImpl::AllocateCaptureDevice 	vie_capture_impl.cc:121
58 	libxul.so 	webrtc::ViECaptureImpl::AllocateExternalCaptureDevice 	vie_capture_impl.cc:150
59 	libxul.so 	mozilla::MediaEngineWebRTCVideoSource::Allocate 	MediaEngineWebRTCVideo.cpp:226
60 	libxul.so 	mozilla::MediaEngineWebRTCVideoSource::ChooseCapability 	MediaEngineWebRTCVideo.cpp:200
61 	libxul.so 	mozilla::GetUserMediaRunnable::ProcessGetUserMedia 	dom/media/MediaManager.cpp:697
62 	libc.so 	libc.so@0x12e52 	
63 	libnss3.so 	PR_Unlock 	nsprpub/pr/src/pthreads/ptsynch.c:205
64 	libxul.so 	mozilla::GetUserMediaRunnable::Run 	dom/media/MediaManager.cpp:558
65 	libnss3.so 	PR_ExitMonitor 	nsprpub/pr/src/pthreads/ptsynch.c:557
66 	libxul.so 	nsEventQueue::GetEvent 	ReentrantMonitor.h:80
67 	libxul.so 	nsThread::ProcessNextEvent 	nsThread.cpp:627
68 	libxul.so 	NS_ProcessNextEvent 	nsThreadUtils.cpp:238
69 	libxul.so 	nsThread::ThreadFunc 	nsThread.cpp:265
70 	libnss3.so 	pt_AttachThread 	nsprpub/pr/src/pthreads/ptthread.c:276
71 	libnss3.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:191
72 	libnss3.so 	pt_AttachThread 	nsprpub/pr/src/pthreads/ptthread.c:276
73 	libc.so 	libc.so@0x12e02 	
74 	libc.so 	libc.so@0x1255a 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=webrtc%3A%3Avideocapturemodule%3A%3ADeviceInfoAndroid%3A%3ANumberOfDevices%28%29

Comment 1

[Jason Smith [:jsmith]]

gcp - any ideas?

Comment 2

[Jason Smith [:jsmith]]

Defensively blocking for gUM, but if we can't do anything here with the given stack or URLs after getting them, feel free to renom.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

There's no URLs provided from this.

My guess is that it may have to do with showing the capture settings and having more than 1 camera.  (front and back)  I think I would have to play around with webrtc on android and understand how webrtc works a little better to figure out how to reproduce the crash.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

This is going to be hard to debug with STR. Seems to imply failure to set up capture_device_info_ with CreateDeviceInfo.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Hard to debug without, of course.

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Do we have a Galaxy S III somewhere?

Samsung Galaxy S III : GT-I9300
ICS : 4.1.2
on Firefox 23a1

Comment 7

[Gian-Carlo Pascutto [:gcp]]

I have one...

Comment 8

[Jason Smith [:jsmith]]

If I had to guess on STR potentially here, I doubt it's a complex STR causing this. We just turned this feature on by default, so if we know the device, I'd say a good way nail down the STR here is go to http://mozilla.github.io/webrtc-landing/gum_test.html and exploratory test the video, audio, video&audio functionality. That might end up revealing the crash.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

I developed the feature on a Nexus 4 and Galaxy S3 using (among others) those pages, so really I do would like to know if there's reliable STR. Maybe it's something simple as order of operations being different from what I tend to do or whatever.

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I don't have the device, so I wouldn't be able to find the STRs as easily.  

My guess would be to try to connect to someone at the same time looking at the settings and changing the capture capability... or something of the nature?

Comment 11

[Jason Smith [:jsmith]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #10)
> I don't have the device, so I wouldn't be able to find the STRs as easily.  
> 
> My guess would be to try to connect to someone at the same time looking at
> the settings and changing the capture capability... or something of the
> nature?

The stack's reference to "number of devices" usually happens as part of the camera capture process for device setup during the perms management flow. So I actually think some testing on a S3 with video or video&audio might be worthwhile.

Comment 12

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Thanks, Jason.  As stated before, I would need the device to test; I'm not sure speculating will lead to any sort of result GCP could use.   I was looking at the bottom of the stack as well as the top to see how things lead to that point.

There's some other scenarioes I would test beyond set up or settings.

Ie what if another app was still using the camera in the background while the WEBRTC was setting up or being configured?  Is there any other ways of switching the cameras in using front or the back one, etc. etc.

Comment 13

[Jason Smith [:jsmith]]

I can't reproduce the crash on a S3 by testing some of the gUM & WebRTC test apps.

Comment 14

[Scoobidiver (away)]

More reports also at: https://crash-stats.mozilla.com/report/list?signature=_JNIEnv%3A%3ACallIntMethod%28_jobject*%2C+_jmethodID*%2C+%2E%2E%2E%29+|+webrtc%3A%3Avideocapturemodule%3A%3ADeviceInfoAndroid%3A%3ANumberOfDevices%28%29

Comment 15

[Tracy Walker [:tracy]]

There are no URLs for either of the signatures.

Comment 16

[Gian-Carlo Pascutto [:gcp]]

We currently set up the Android objects in EnumerateVideoDevices, but there is some evidence we can be setting up things without passing through there, see for example https://bugzilla.mozilla.org/show_bug.cgi?id=866093#c1

Comment 17

[Gian-Carlo Pascutto [:gcp]]

Okay, jesup confirmed that also for video it's perfectly possible to start without going through EnumerateVideoDevices. The current code assumes that those functions are called first and will do the SetAndroidObjects call.

This would be consistent with this crash signature, so fingers crossed. Jesup, do you know STR to reproduce this situation?

Comment 18

[Gian-Carlo Pascutto [:gcp]]

Got this while running under the debugger, yay:

Program received signal SIGSEGV, Segmentation fault.
Loading libraries and symbols...
[Switching to Thread 14070]
0x408ba6da in ?? () from /home/morbo/jimdb/moz-gdb/lib/00658c727e962a43/system/lib/libdvm.so
(gdb) bt
#0  0x408ba6da in ?? () from /home/morbo/jimdb/moz-gdb/lib/00658c727e962a43/system/lib/libdvm.so
#1  0x7bbff3ca in _JNIEnv::CallIntMethod (this=<optimized out>, obj=<optimized out>, methodID=0x6d14e118)
    at /home/morbo/android-ndk-r8c/platforms/android-9/arch-arm/usr/include/jni.h:637
#2  0x7cafcaa4 in webrtc::videocapturemodule::DeviceInfoAndroid::NumberOfDevices (this=0x771fe0a0)
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc:72
#3  0x7cb59128 in webrtc::ViEInputManager::NumberOfCaptureDevices (this=0x7712a040)
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_input_manager.cc:75
#4  0x7cb3f516 in webrtc::ViECaptureImpl::NumberOfCaptureDevices (this=0x77c752c0)
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_capture_impl.cc:80
#5  0x7b860d06 in mozilla::MediaEngineWebRTC::EnumerateVideoDevices (this=0x7f13e340, aVSources=0x824ffda4)
    at /home/morbo/hg/mozilla-central/content/media/webrtc/MediaEngineWebRTC.cpp:110
#6  0x7b9ffc5a in mozilla::GetUserMediaRunnable::SelectDevice (this=0x7f3f38d0)
    at /home/morbo/hg/mozilla-central/dom/media/MediaManager.cpp:613
#7  0x7ba03eae in mozilla::GetUserMediaRunnable::Run (this=0x7f3f38d0)
    at /home/morbo/hg/mozilla-central/dom/media/MediaManager.cpp:537
#8  0x7c654d7c in nsThread::ProcessNextEvent (this=0x7f1cee40, mayWait=<optimized out>, result=0x824ffe87)
    at /home/morbo/hg/mozilla-central/xpcom/threads/nsThread.cpp:627
#9  0x7c604076 in NS_ProcessNextEvent (thread=<optimized out>, mayWait=<optimized out>)
    at /home/morbo/hg/mozilla-central/objdir-android/xpcom/build/nsThreadUtils.cpp:238
#10 0x7c6542d2 in nsThread::ThreadFunc (arg=0x7f1cee40) at /home/morbo/hg/mozilla-central/xpcom/threads/nsThread.cpp:265
#11 0x773fbdf4 in _pt_root (arg=0x7851c600) at /home/morbo/hg/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:204
#12 0x402743dc in __thread_entry () from /home/morbo/jimdb/moz-gdb/lib/00658c727e962a43/system/lib/libc.so
#13 0x40273ac8 in pthread_create () from /home/morbo/jimdb/moz-gdb/lib/00658c727e962a43/system/lib/libc.so

Comment 19

[Gian-Carlo Pascutto [:gcp]]

EnumerateVideoDevices is in that stack, so bug 866093 probably won't solve this.

Comment 20

[Gian-Carlo Pascutto [:gcp]]

D/*WEBRTCN*(16302): SetAndroidObjects: Registered native functions
D/*WEBRTCN*(16302): VideoCaptureDeviceInfoAndroid get method id
D/*WEBRTCN*(16302): SetAndroidObjects: construct static java device object
D/WEBRTC  (16302): VideoCaptureDeviceInfoAndroid
D/WEBRTC  (16302): Camera 0, Facing back, Orientation 90
...
E/mm-camera(  191): mctl_open_and_init_comps: mctl_open_comps failed, rc = -1
E/mm-libcamera2(11271): mm_camera_util_private_s_ctrl: fd=31, S_CTRL, id=0x800000d, value = 0x42be3950, rc = -1
E/QCameraHWI_Parm(11271): native_set_parms failed: type 3 length 424 error Connection timed out
E/QCameraHWI_Parm(11271): MM_CAMERA_PARM_DIMENSION Failed.
..
E/WEBRTC  (16302): Failed to init VideoCaptureDeviceInfo exnull
D/WEBRTC  (16302): Failed to create VideoCaptureDeviceInfoAndroid.
D/*WEBRTCN*(16302): SetAndroidObjects: could not create Java Capture Device info object

Comment 21

[Gian-Carlo Pascutto [:gcp]]

Okay, I got the cause: this happens if the camera in the device gets stuck for whatever reason and we fail to open it. 

We generate an exception around:
https://mxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/video_capture/android/java/org/webrtc/videoengine/VideoCaptureDeviceInfoAndroid.java#114

And the calling code doesn't deal very well with the missing camera.

This is probably why it's hard to reproduce; I don't know any good way to get the Android Camera stuck. It happened just once on this Nexus 4 and this bug was 100% reproducible then. After rebooting, it's not reproducible at all.

Also note the Android camera errors in the logcat above?

Comment 22

[Jason Smith [:jsmith]]

Sounds like STR is going to be hard to get here then. I'll pull the keyword, but based on what I'm seeing above, you've got an idea on some of the problems underlying this crash, so we might be okay.

Comment 23

[Jason Smith [:jsmith]]

Bouncing back up to a blocker now that momentum is possible.

Comment 24

[Gian-Carlo Pascutto [:gcp]]

Attachment: Patch 1. Detect SetObjects failure. Initialize objects.

Add error handling for SetObjects failure. After fixing that we still crash because VideoConduit doesn't null it's pointers on construction, but does check them for nullness in the destructor. Fixed that too.

Comment 25

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 746314 [details] [diff] [review]
Patch 1. Detect SetObjects failure. Initialize objects.

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

::: media/webrtc/signaling/src/media-conduit/VideoConduit.h
@@ +159,5 @@
> +                      mPtrViECodec(NULL),
> +                      mPtrViENetwork(NULL),
> +                      mPtrViERender(NULL),
> +                      mPtrExtCapture(NULL),
> +                      mPtrRTP(NULL)

nullptr please for all of these (and the other ones right above).

Comment 26

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4b3a3f40730f

Comment 27

[Gian-Carlo Pascutto [:gcp]]

Backed it out, for some reason it's causing Android 4.0 (but not 2.2) orange.

https://hg.mozilla.org/integration/mozilla-inbound/rev/e698d3534b96

Comment 28

[Gian-Carlo Pascutto [:gcp]]

05-07 23:32:49.765 E/WEBRTC  ( 2197): Failed to init VideoCaptureDeviceInfo exnull
05-07 23:32:49.765 W/CameraService( 1294): CameraService::connect X (pid 2197) rejected (existing client).
05-07 23:32:49.773 E/WEBRTC  ( 2197): Failed to init VideoCaptureDeviceInfo exFail to connect to camera service

We fail to open the camera, subsequent opens continue to fail because we are already holding the lock.

The tests pass on my local devices.

Comment 29

[Gian-Carlo Pascutto [:gcp]]

More logging, getting the available frame rates fails:

05-14 11:26:34.718 D/WEBRTC  ( 2205): VideoCaptureDeviceInfoAndroid
05-14 11:26:34.726 D/****CameraHAL( 1293): 413: camera_get_camera_info() ENTER
05-14 11:26:34.726 D/****CameraHAL( 1293): cameraHal BACK 0
05-14 11:26:34.726 D/****CameraHAL( 1293): cameraHal 0
05-14 11:26:34.726 D/WEBRTC  ( 2205): Camera 0, Facing back, Orientation 0
05-14 11:26:34.726 D/WEBRTC  ( 2205): Opening Camera 0
05-14 11:26:34.726 D/****CameraHAL( 1293): 413: camera_get_camera_info() ENTER
05-14 11:26:34.726 D/****CameraHAL( 1293): cameraHal BACK 0
05-14 11:26:34.726 D/****CameraHAL( 1293): cameraHal 0
05-14 11:26:34.726 I/CameraService( 1293): Opening camera 0
05-14 11:26:34.726 D/****CameraHAL( 1293): 314: camera_device_open() ENTER
05-14 11:26:34.726 I/****CameraHAL( 1293): camera_device open
05-14 11:26:34.726 D/CameraHardware( 1293): PREVIEW SIZE: w=320 h=240 framerate=30
05-14 11:26:34.726 D/****CameraHAL( 1293): 120: camera_set_callbacks() ENTER
05-14 11:26:34.726 D/****CameraHAL( 1293): 128: camera_enable_msg_type() ENTER
05-14 11:26:34.726 I/AwesomePlayer( 1293): setDataSource_l('/system/media/audio/ui/camera_click.ogg')
05-14 11:26:34.750 I/AwesomePlayer( 1293): setDataSource_l('/system/media/audio/ui/VideoRecord.ogg')
05-14 11:26:34.757 D/WEBRTC  ( 2205): Getting Camera 0 parameters
05-14 11:26:34.757 D/****CameraHAL( 1293): focus-mode=0;picture-format=jpeg;picture-size=320x240;picture-size-values=320x240;preview-format=yuv422sp;preview-fps-range-values=(8000,8000),(8000,10000),(10000,10000),(8000,15000),(15000,15000),(8000,20000),(20000,20000),(24000,24000),(25000,25000),(8000,30000),(30000,30000);preview-frame-rate=30;preview-size=320x240;preview-size-values=320x240,352x288,640x480,720x480,720x576,848x480;video-frame-format=yuv420sp
05-14 11:26:34.757 D/****CameraHAL( 1293): 249: camera_get_parameters() ENTER
05-14 11:26:34.757 D/****CameraHAL( 1293): 255: camera_put_parameters() ENTER
05-14 11:26:34.757 D/CameraHardware( 1293): PREVIEW SIZE: w=320 h=240 framerate=30
05-14 11:26:34.765 D/WEBRTC  ( 2205): Getting Camera 0 resolutions & framerates
05-14 11:26:34.765 E/WEBRTC  ( 2205): Failed to init VideoCaptureDeviceInfo exception: null
05-14 11:26:34.765 D/****CameraHAL( 1293): 135: camera_disable_msg_type() ENTER
05-14 11:26:34.765 D/****CameraHAL( 1293): 135: camera_disable_msg_type() ENTER
05-14 11:26:34.765 D/****CameraHAL( 1293): 154: camera_stop_preview() ENTER
05-14 11:26:34.765 D/****CameraHAL( 1293): 226: camera_cancel_picture() ENTER
05-14 11:26:34.765 D/****CameraHAL( 1293): 272: camera_release() ENTER
05-14 11:26:34.765 I/CameraService( 1293): Destroying camera 0
05-14 11:26:34.765 D/****CameraHAL( 1293): 289: camera_device_close() ENTER
05-14 11:26:34.765 D/WEBRTC  ( 2205): Failed to create VideoCaptureDeviceInfoAndroid.
05-14 11:26:34.765 D/WEBRTC  ( 2205): VideoCaptureDeviceInfoAndroid

Comment 30

[Gian-Carlo Pascutto [:gcp]]

Attachment: Patch 1. v2 Detect SetObjects failure. Initialize objects.

Improved version of previous patch:

1) Don't try to use the Java Env if attaching to it fails. (Didn't see any crashers with this, but it's an obvious bug.
2) The Android 4.0 test boards will fail getSupportedPreviewFrameRates(). This is allowed by the Android API but the code didn't handle it.
3) Android 2.2 wouldn't report any cameras back. Added some simple code to handle it.

Comment 31

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 749869 [details] [diff] [review]
Patch 1. v2 Detect SetObjects failure. Initialize objects.

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

r+
Please also submit an issue on webrtc.org and a patch to reitveld and put links in a comment here.

Comment 32

[Gian-Carlo Pascutto [:gcp]]

https://code.google.com/p/webrtc/issues/detail?id=1778

Comment 33

[Gian-Carlo Pascutto [:gcp]]

https://code.google.com/p/webrtc/issues/detail?id=1780

Hmm, my patches will have slight differences due to our changes in these files, and I won't be able to test anything I rebase. I linked the issues to the patches here, if anyone at webrtc.org cares they can pick them up.

Comment 34

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/344e5e78adaa

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/344e5e78adaa

Comment 36

[Scoobidiver (away)]

It's not fixed. See the link in comment 0.

Comment 37

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 749869 [details] [diff] [review]
Patch 1. v2 Detect SetObjects failure. Initialize objects.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 750010 and friends
User impact if declined: Crashes when trying to use WebRTC
Testing completed (on m-c, etc.): Landed on m-c a few days ago. Doesn't solve all crashes but fixes reall bugs.
Risk to taking this patch (and alternatives if risky): Don't care about WebRTC stability for 23. Little risk, change in preffed-off feature.

Comment 38

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 749869 [details] [diff] [review]
Patch 1. v2 Detect SetObjects failure. Initialize objects.

Approving for uplift to increase webrtc stability.

Comment 39

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/67f17b73c834

Comment 40

[Scoobidiver (away)]

A comment in French (post-patch) says: "I was using WebRTC, switched to the Android desktop then launched again WebRTC"

Comment 41

[Gian-Carlo Pascutto [:gcp]]

That sounds like bug 874546 expect it wouldn't produce this backtrace at all.

Comment 42

[Jason Smith [:jsmith]]

One interesting comment came in:

I was using two websites that tried to access getUserMedia - not at the same time. one (the one that crashed) was still displaying the prompt for sharing when I came back from testing the other one. I pressed share and it crashed. let me know if you need more info!

Maybe this has to do with multiple tabs using getUserMedia? Let's do qawanted on that.

Comment 43

[Jason Smith [:jsmith]]

We're crashing enough here even nightly that I'm concerned that as we go up to higher branches, the rate of crashes here will spike. We shouldn't lose this on our radar - we need to narrow this down to find out what's crashing us here. comment 42 gives a clue.

Comment 44

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #43)
> We're crashing enough here even nightly that I'm concerned that as we go up
> to higher branches, the rate of crashes here will spike. We shouldn't lose
> this on our radar - we need to narrow this down to find out what's crashing
> us here. comment 42 gives a clue.

Wasn't able to find anything sadly. I did hit the other crash in bug 880437, however.

Comment 45

[Jason Smith [:jsmith]]

Can't block until we have something actionable here.

Comment 46

[Scoobidiver (away)]

(In reply to Gian-Carlo Pascutto (:gcp) from comment #41)
> That sounds like bug 874546 expect it wouldn't produce this backtrace at all.
Currently no crashes since 24.0a1/20130606 when the patch of bug 874546 landed.

Comment 47

[Jason Smith [:jsmith]]

(In reply to Scoobidiver from comment #46)
> (In reply to Gian-Carlo Pascutto (:gcp) from comment #41)
> > That sounds like bug 874546 expect it wouldn't produce this backtrace at all.
> Currently no crashes since 24.0a1/20130606 when the patch of bug 874546
> landed.

I'm going to close this for now since bug 874546 fixed this and we haven't seen crashes over a few days. If we end up seeing these crashes again, reopen the bug.

Comment 48

[Jason Smith [:jsmith]]

We're only preffing on Fx24, not 23. So I'm marking 23 as disabled.