crash in webrtc::videocapturemodule::VideoCaptureAndroid::AttachAndUseAndroidDeviceInfoObjects

VERIFIED FIXED in Firefox 25

Status

()

Core
WebRTC: Audio/Video
--
critical
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Scoobidiver (away), Assigned: gcp)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla27
ARM
Android
crash, reproducible, testcase, verifyme
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox24 wontfix, firefox25 fixed, firefox26 fixed, firefox27 verified, fennec24+)

Details

(Whiteboard: [native-crash][getUserMedia][android-gum-], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
It has been hit by one user several times in Aurora 24.

Signature 	webrtc::videocapturemodule::VideoCaptureAndroid::AttachAndUseAndroidDeviceInfoObjects(_JNIEnv*&, _jclass*&, _jobject*&, bool&) More Reports Search
UUID 	c3ebb35b-8cf0-4a2a-824d-fe48b2130806
Date Processed	2013-08-06 19:26:03.867553
Uptime	5328
Last Crash	465589 seconds before submission
Install Age 	498010 since version was first installed.
Install Time 	2013-08-01 01:05:44
Product 	FennecAndroid
Version 	24.0a2
Build ID 	20130726004002
Release Channel 	aurora
OS 	Android
OS Version 	0.0.0 Linux 3.4.0-perf-gf43c3d9 #1 SMP PREEMPT Mon Jun 17 16:55:05 PDT 2013 armv7l google/occam/mako
Build Architecture 	arm
Build Architecture Info 	ARMv0 | 4
Crash Reason 	SIGSEGV
Crash Address 	0x2c
App Notes 	
AdapterDescription: 'Qualcomm -- Adreno (TM) 320 -- OpenGL ES 3.0 V@14.0 (GIT@Iabe52cfaeae4c5fab1acacfe6f056ba15fa93274) -- Model: Nexus 4, Product: occam, Manufacturer: LGE, Hardware: mako'
GL Layers! EGL? EGL+ GL Context? GL Context+ GL Layers+ 
LGE Nexus 4
google/occam/mako:4.3/JWR66V/737497:user/release-keys

Frame 	Module 	Signature 	Source
0 	libdvm.so 	libdvm.so@0x4cdd8 	
1 	libxul.so 	webrtc::videocapturemodule::VideoCaptureAndroid::AttachAndUseAndroidDeviceInfoObjects(_JNIEnv*&, _jclass*&, _jobject*&, bool&) 	media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc
2 	libxul.so 	webrtc::videocapturemodule::DeviceInfoAndroid::NumberOfDevices() 	media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc
3 	libxul.so 	webrtc::ViEInputManager::CreateCaptureDevice(char const*, unsigned int, int&) 	media/webrtc/trunk/webrtc/video_engine/vie_input_manager.cc
4 	libxul.so 	webrtc::ViECaptureImpl::AllocateCaptureDevice(char const*, unsigned int, int&) 	media/webrtc/trunk/webrtc/video_engine/vie_capture_impl.cc
5 	libxul.so 	mozilla::MediaEngineWebRTCVideoSource::Allocate(mozilla::MediaEnginePrefs const&) 	content/media/webrtc/MediaEngineWebRTCVideo.cpp
6 	libxul.so 	mozilla::GetUserMediaRunnable::ProcessGetUserMedia(mozilla::MediaEngineSource*, mozilla::MediaEngineSource*) 	dom/media/MediaManager.cpp
7 	libxul.so 	mozilla::GetUserMediaRunnable::Run() 	dom/media/MediaManager.cpp
8 	libxul.so 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
9 	libxul.so 	NS_ProcessNextEvent(nsIThread*, bool) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
10 	libxul.so 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
11 	libnss3.so 	_pt_root 	/builds/slave/oak-and-0000000000000000000000/build/obj-firefox/nsprpub/pr/src/pthreads/../../../../../nsprpub/pr/src/pthreads/ptthread.c
12 	libc.so 	libc.so@0xca5a 	
13 	libc.so 	libc.so@0xcbd6 	

More reports at:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&signature=webrtc%3A%3Avideocapturemodule%3A%3AVideoCaptureAndroid%3A%3AAttachAndUseAndroidDeviceInfoObjects%28_JNIEnv*%26%2C+_jclass*%26%2C+_jobject*%26%2C+bool%26%29
(Reporter)

Updated

4 years ago
status-firefox26: --- → affected
Version: 24 Branch → Trunk

Updated

4 years ago
Whiteboard: [native-crash] → [native-crash][getUserMedia][android-gum-]

Updated

4 years ago
Duplicate of this bug: 908368
Steps in the duplicate bug above from ekr.

Comment 3

4 years ago
I can reproduce this fairly reliably. If there is something simple you would like me to do, please LMK.
gcp - is this potentially a dupe of bug 887227 by any chance? The stacks look similar.

Frame 	Module 	Signature 	Source
0 	libdvm.so 	libdvm.so@0x4cdd8 	
1 	libxul.so 	webrtc::videocapturemodule::VideoCaptureAndroid::AttachAndUseAndroidDeviceInfoObjects(_JNIEnv*&, _jclass*&, _jobject*&, bool&) 	media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc
2 	libxul.so 	webrtc::videocapturemodule::DeviceInfoAndroid::NumberOfDevices() 	media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc
3 	libxul.so 	webrtc::ViEInputManager::CreateCaptureDevice(char const*, unsigned int, int&) 	media/webrtc/trunk/webrtc/video_engine/vie_input_manager.cc
4 	libxul.so 	webrtc::ViECaptureImpl::AllocateCaptureDevice(char const*, unsigned int, int&) 	media/webrtc/trunk/webrtc/video_engine/vie_capture_impl.cc
5 	libxul.so 	mozilla::MediaEngineWebRTCVideoSource::Allocate(mozilla::MediaEnginePrefs const&) 	content/media/webrtc/MediaEngineWebRTCVideo.cpp
6 	libxul.so 	mozilla::GetUserMediaRunnable::ProcessGetUserMedia(mozilla::MediaEngineSource*, mozilla::MediaEngineSource*) 	dom/media/MediaManager.cpp
7 	libxul.so 	mozilla::GetUserMediaRunnable::Run() 	dom/media/MediaManager.cpp
8 	libxul.so 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
9 	libxul.so 	NS_ProcessNextEvent(nsIThread*, bool) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
10 	libxul.so 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
11 	libnss3.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c
Flags: needinfo?(gpascutto)
(Assignee)

Comment 5

4 years ago
It's a potential dupe of many of the outstanding WebRTC Android crashers, due to the same underlying cause. So also bug 887693 for example.
Flags: needinfo?(gpascutto)
(In reply to Gian-Carlo Pascutto (:gcp) from comment #5)
> It's a potential dupe of many of the outstanding WebRTC Android crashers,
> due to the same underlying cause. So also bug 887693 for example.

Okay. If it's a potential dupe due to be the same underlying cause as bug 887227, I'll keep this open separate. We do have STR on this bug. Also looks like you can reproduce the crash (even though the stack is pointing at bug 887227, but we think it's the same underlying cause). We know that for the three bugs involving this same underlying cause is producing a significant amount of crashes weekly:

Last 7 days:

bug 887227 - 44 crashes
bug 887693 - 4 crashes
bug 902431 - 3 crashes

Those three bugs also happen to be the top 4 crash stacks seen in crash stats for webrtc right now.

We have STR & a webrtc top crash on fxandroid. I'd say let's push for a fix here.
tracking-fennec: --- → ?
Assignee: nobody → gpascutto
tracking-fennec: ? → 24+
(Assignee)

Comment 7

4 years ago
This has been a bit nasty to debug, but two relevant, corresponding bits of logging:

745728[73752580]: Audio: NotifyPull: aDesiredTime 0, target 14682859, delta 0
3252984[70cc1800]: Audio device 0 deallocated
3252984[70cc1800]: Stop
5745728[73752580]: Audio: NotifyPull: aDesiredTime 0, target 14691248, delta 0
5745728[73752580]: Listener removed by DOM Destroy(), mFinished = 0
3252984[70cc1800]: Deallocate
5398544[71a33f80]:   Capture Device Index 0, Name Camera 0, Facing back, Orientation 0
5398544[71a33f80]: Number of Capabilities 2
5398544[71a33f80]: type=12 width=640 height=480 maxFPS=30
5398544[71a33f80]: type=12 width=1024 height=768 maxFPS=30
5398544[71a33f80]:   Capture Device Index 1, Name Camera 1, Facing front, Orientation 0
3252984[70cc1800]: Video device 4097 deallocated
3252984[70cc1800]: Stop
3252984[70cc1800]: Deallocate
5398544[71a33f80]: Number of Capabilities 2
5398544[71a33f80]: type=12 width=320 height=240 maxFPS=30
5398544[71a33f80]: type=12 width=800 height=600 maxFPS=30
2905000[5c343200]: MediaCaptureWindowState: window 26 capturing  
2905000[5c343200]: MediaCaptureWindowState: window 26 capturing  
3252984[70cc1800]: Audio device 0 allocated
3252984[70cc1800]: Allocate
~~crash~~

APICALL   ; (17:56:53:554 |    1)        VIDEO:    0     1;      4190; ViEBase::Release()
DEBUGINFO ; (17:56:53:554 |    1)        VIDEO:    0     1;      4190; ViEBase reference count: 2
APICALL   ; (17:56:53:554 |    0)        VIDEO:    0     1;      4190; ViECapture::Release()
DEBUGINFO ; (17:56:53:554 |    0)        VIDEO:    0     1;      4190; ViECapture reference count: 2
MEMORY    ; (17:56:53:554 |    0) AUDIO DEVICE:         -1;      4190; SetAndroidAudioDeviceObjects called
STATEINFO ; (17:56:53:554 |    0) AUDIO DEVICE:         -1;      4190; SetAndroidAudioDeviceObjects: env is NULL, assuming deinit
WARNING   ; (17:56:53:554 |    0) AUDIO DEVICE:         -1;      4190; SetAndroidAudioDeviceObjects: saved env already NULL
APICALL   ; (17:56:53:554 |    0)        VOICE:    1    99;      4190; 

The last log indicates SetAndroidObjects has been called with a NULL JVM, which the code takes as a request to free up and de-initialize stuff. However, we don't actually do this intentionally anywhere, as the objects can persist for the lifetime of the Fennec process anyway, so there's no pressing reason to clean them up. This seems to indicate the code fails to get the JVM at some point, and this is misinterpreted as an attempt to clean up the Android capture stack.
(Assignee)

Comment 8

4 years ago
And when you try to break into the case where we're freeing up stuff, the call stack looks like this:

Breakpoint 1, webrtc::videocapturemodule::VideoCaptureAndroid::SetAndroidObjects (javaVM=0xf2f8, javaContext=0x4073c738)
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc:172
172	                 "%s: JVM is NULL, assuming deinit", __FUNCTION__);
(gdb) bt
#0  webrtc::videocapturemodule::VideoCaptureAndroid::SetAndroidObjects (javaVM=0xf2f8, javaContext=0x4073c738)
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc:172
#1  0x6ffe0000 in ?? ()
#2  0x6ffe0000 in ?? ()

Which isn't helping.
24 wont-fix?

Comment 10

4 years ago
(In reply to Aaron Train [:aaronmt] from comment #9)
> 24 wont-fix?

Given that the STR for this bug are a very straightforward series of actions that our users will plausibly perform with some regularity, I don't see how we can consider shipping with this crasher unfixed. I know the "end-of-game" buzzer has gone off for 24, but I think that points to a need to pref off rather than shipping something that we know crashes under common usage scenarios.
(Assignee)

Comment 11

4 years ago
Note that those STR don't always reproduce the crash (unfortunately!). In my testing, it's more like 20% odds, with the odds bigger that after a few iterations of the STR WebRTC simply won't start until you restart Fennec. It's clear that this bug and its relatives mean that the odds of crashing when trying to set up WebRTC are non-negligible, though.

I'm actively debugging this right now but this is not an easy problem, and there's no guarantee the fix will be simple.
I don't know if this helps, but on my Nexus 7, it's quite reliable.

Perhaps some kind of clue...
(Assignee)

Comment 13

4 years ago
Okay, I'll try a few more devices. If it's say >75% odds of hitting it, it may be valgrindable where the stack gets smashed.
This crash stack specifically appears to be showing up for:

- Nexus 7
- Nexus 10
- Nexus 4

No other devices seem to be present in crash stats.

FWIW - I can't reproduce this crash with Ekr's STR on a Galaxy Nexus on Android 4.2. Maybe this is a Nexus-specific?
Testing this afternoon on a Nexus 7 (2012, Android 4.3), Nexus 4 (Android 4.3), and Nexus 7 (2013, Android 4.3); I have hit this crash once on my Nexus 7 (2012, Android 4.3) device using the steps to reproduce using the steps in bug 908368 comment #0. All media re-acquisition on other occasions does not crash for me, but I do tend to get errors after sharing my camera the second time.

E/NvOmxCamera(  124): OMX_ERRORTYPE android::NvOmxCamera::getCameraStereoMode(NvxComponent*, NvOmxCameraUserStereoMode&): Error: invalid NVX mode 0.

E/NvOmxCamera(  124): OMX_ERRORTYPE android::NvOmxCamera::getCameraStereoModeAndCaptureInfo(NvxComponent*, NvOmxCameraUserStereoMode&, NVX_STEREOCAPTUREINFO&): getCameraStereoMode failed with 0x00000000

and when that happens and you want to correct things by closing the active tab, you run into bug 904784.

Crash report from my Nexus 7

https://crash-stats.mozilla.com/report/index/87818e5d-79dd-4d04-8970-60b382130904
Also reproducible on the same Nexus 7 when (media.navigator.permission.disabled) and just brute force reloading http://www.simpl.info/getusermedia/ after a half dozen reloads or so I crashed (different signature though), but these steps might be helpful to catch into a debugger.

https://crash-stats.mozilla.com/report/index/1662ea25-be64-42cd-882d-dffc42130904
Created attachment 799865 [details]
Test Case (Disable Permission Prompt When Running This)
Can you try testing the attached test case to see if you can reproduce on a Nexus 7 a few times in a row? I'm trying to confirm if this a confirmed reduced test case or not. I think it is, but I need someone to check.
Flags: needinfo?(aaron.train)
Indeed, same idea as what I posted. I can crash with that script test-case (w and w/o permission interference). As well, I can crash on my Nexus 4 (Android 4.3) with that as well alongside my Nexus 7.

Nexus 4 (Android 4.3): https://crash-stats.mozilla.com/report/index/c494b555-04b4-4495-86e4-cc4082130905

As well, I can crash on my GT-I9505 (Samsung Galaxy S4) (and likely other devices too)

https://crash-stats.mozilla.com/report/index/49da4430-1ae8-4d94-a9e8-a58a32130905
Flags: needinfo?(aaron.train)
Keywords: testcase

Updated

4 years ago
Keywords: reproducible
Devices reproducible with so far:

- Nexus 4
- Nexus 7
- Nexus 10
- Galaxy S4

Devices not reproducible so far:

- Galaxy Nexus
Other devices using same process in comment #19

- HTC One (Android 4.3, Google Play Edition)

https://crash-stats.mozilla.com/report/index/633411f2-b917-4848-a6c4-83efa2130906

- Samsung Galaxy Note II (Android 4.2)

https://crash-stats.mozilla.com/report/index/38ad9343-f7c5-462e-bf71-fd19c2130906

- Samsung Galaxy SII (Android 4.1.2)

https://crash-stats.mozilla.com/report/index/e65d02fc-214d-479b-bdf5-b34722130906
Strange. So testing again today on a galaxy nexus 4.2, I didn't reproduce the crash, but instead I got the FxAndroid process to entirely hang with the attached test case.
(In reply to Aaron Train [:aaronmt] from comment #21)
> Other devices using same process in comment #19
> 
> - HTC One (Android 4.3, Google Play Edition)
> 
> https://crash-stats.mozilla.com/report/index/633411f2-b917-4848-a6c4-
> 83efa2130906
> 
> - Samsung Galaxy Note II (Android 4.2)
> 
> https://crash-stats.mozilla.com/report/index/38ad9343-f7c5-462e-bf71-
> fd19c2130906
> 
> - Samsung Galaxy SII (Android 4.1.2)
> 
> https://crash-stats.mozilla.com/report/index/e65d02fc-214d-479b-bdf5-
> b34722130906bug 887277's signature
Upon doing further testing on a Galaxy Nexus, I now can reproduce the crash consistently 100%, but I'm getting the stack seen in bug 887227 instead. See https://bugzilla.mozilla.org/show_bug.cgi?id=887227#c9.

Updated

4 years ago
Blocks: 887227
(Assignee)

Comment 25

4 years ago
jchen got this stack while looking at another bug, which looks relevant:

#0  0x4092fad8 in dvmAbort () from /home/nchen/android-gdb/lib/016ec233976516f7/system/lib/libdvm.so
#1  0x409343be in dvmDecodeIndirectRef(Thread*, _jobject*) () from /home/nchen/android-gdb/lib/016ec233976516f7/system/lib/libdvm.so
#2  0x40937142 in ?? () from /home/nchen/android-gdb/lib/016ec233976516f7/system/lib/libdvm.so
#3  0x7925ba62 in NewGlobalRef (obj=0x42934298, this=<optimized out>) at /home/nchen/ndk/platforms/android-14/arch-arm/usr/include/jni.h:563
#4  webrtc::videocapturemodule::VideoCaptureAndroid::SetAndroidObjects (javaVM=<optimized out>, javaContext=0x24c004ee) at /home/nchen/aurora/media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc:151
#5  0x79288b98 in webrtc::VideoEngine::SetAndroidObjects (javaVM=0x4207cc80, javaContext=0x24c004ee) at /home/nchen/aurora/media/webrtc/trunk/webrtc/video_engine/vie_impl.cc:212
#6  0x78a880e4 in mozilla::MediaEngineWebRTC::EnumerateVideoDevices (this=0x80cd1dc0, aVSources=0x82bffe28) at /home/nchen/aurora/content/media/webrtc/MediaEngineWebRTC.cpp:100
#7  0x78b24454 in mozilla::GetUserMediaDevicesRunnable::Run (this=0x809664a0) at /home/nchen/aurora/dom/media/MediaManager.cpp:862
#8  0x78ffc5ec in nsThread::ProcessNextEvent (this=0x8038c460, mayWait=<optimized out>, result=0x82bffea7) at /home/nchen/aurora/xpcom/threads/nsThread.cpp:622
#9  0x78fdce2e in NS_ProcessNextEvent (thread=<optimized out>, mayWait=<optimized out>) at /home/nchen/aurora/objdir-android/xpcom/build/nsThreadUtils.cpp:238
#10 0x78ffc6f0 in nsThread::ThreadFunc (arg=0x8038c460) at /home/nchen/aurora/xpcom/threads/nsThread.cpp:250
#11 0x76b9b42e in _pt_root (arg=0x80d35980) at /home/nchen/aurora/nsprpub/pr/src/pthreads/ptthread.c:204
#12 0x400cda5c in __thread_entry () from /home/nchen/android-gdb/lib/016ec233976516f7/system/lib/libc.so
#13 0x400cdbd8 in pthread_create () from /home/nchen/android-gdb/lib/016ec233976516f7/system/lib/libc.so
#14 0x00000000 in ?? ()
(Assignee)

Comment 26

4 years ago
This trace indicates that
http://mxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc#139
returns an invalid object. From the code there's no way that can happen, it's either null (checked for) or a new VideoCaptureDeviceInfoAndroid.

I made a guess here that if the factory method throws an exception, this might mess things up as the JNI code doesn't check for exceptions. Unfortunately adding a catch() around everything and returning null in the factory method doesn't make the crash go away. Too bad - this would have been a reasonable explanation :-P
(Assignee)

Comment 27

4 years ago
Status so far:

Galaxy Tab 10.1, Android 3.2:
- Both testcases reproduce the bug, the simpl.info one is 100% reproducible if the website can be loaded. About half the time, the browser has a total freeze when loading the site, and in fact it's frozen so hard I can't break into it with the debugger. I suspected bug 915671 for a bit but that shouldn't stop the debugger. In some cases the tablet does a total reboot after this.

Nexus S, Android 4.0.4:
- Not reproducible on either testcase.

Nexus 4, Android 4.3:
- Not reproducible on either testcase. I got one lockup similar to the Galaxy Tab on simpl.info (I presume comment 22 refers to this).

However, on the Nexus 4, after iterating many times, I eventually got this:

W/dalvikvm(16617): JNI local reference table (0x82713008) dump:
W/dalvikvm(16617):   Last 10 entries (of 512):
W/dalvikvm(16617):       511: 0x41f5f4b0 org.webrtc.videoengine.CaptureCapabilityAndroid
W/AudioFlinger(  174): session id 236 not found for pid 174
W/dalvikvm(16617):       510: 0x41f5f2a0 org.webrtc.videoengine.CaptureCapabilityAndroid
W/dalvikvm(16617):       509: 0x41f5f258 org.webrtc.videoengine.CaptureCapabilityAndroid[] (12 elements)
W/dalvikvm(16617):       508: 0x422b7810 java.lang.String "Camera 1, Facing... (39 chars)
W/dalvikvm(16617):       507: 0x42321eb0 java.lang.String "Camera 1, Facing... (39 chars)
W/dalvikvm(16617):       506: 0x422c38a0 java.lang.String "Camera 0, Facing... (37 chars)
W/dalvikvm(16617):       505: 0x42347cf0 org.webrtc.videoengine.CaptureCapabilityAndroid
W/dalvikvm(16617):       504: 0x42347ae0 org.webrtc.videoengine.CaptureCapabilityAndroid
W/dalvikvm(16617):       503: 0x42260020 org.webrtc.videoengine.CaptureCapabilityAndroid
W/dalvikvm(16617):       502: 0x4225fe10 org.webrtc.videoengine.CaptureCapabilityAndroid
W/AudioFlinger(  174): session id 237 not found for pid 174
W/dalvikvm(16617):   Summary:
W/dalvikvm(16617):        80 of java.lang.String (69 unique instances)
W/dalvikvm(16617):       398 of org.webrtc.videoengine.CaptureCapabilityAndroid (266 unique instances)
W/dalvikvm(16617):        34 of org.webrtc.videoengine.CaptureCapabilityAndroid[] (12 elements) (23 unique instances)
E/dalvikvm(16617): Failed adding to JNI local ref table (has 512 entries)
I/dalvikvm(16617): "Thread-357" prio=5 tid=33 RUNNABLE
I/dalvikvm(16617):   | group="main" sCount=0 dsCount=0 obj=0x422de5f8 self=0x851f50f8
I/dalvikvm(16617):   | sysTid=16820 nice=0 sched=0/0 cgrp=apps handle=-2113329768
I/dalvikvm(16617):   | state=R schedstat=( 0 0 0 ) utm=85 stm=26 core=2
I/dalvikvm(16617):   at dalvik.system.NativeStart.run(Native Method)
I/dalvikvm(16617): 

rogram received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16820]
0x408c9ad8 in dvmAbort () from /home/morbo/git/android-gdb/moz-gdb/lib/00658c727e962a43/system/lib/libdvm.so
(gdb) bt
#0  0x408c9ad8 in dvmAbort () from /home/morbo/git/android-gdb/moz-gdb/lib/00658c727e962a43/system/lib/libdvm.so
#1  0x408ccf5e in ?? () from /home/morbo/git/android-gdb/moz-gdb/lib/00658c727e962a43/system/lib/libdvm.so
#2  0x408cf1d8 in ?? () from /home/morbo/git/android-gdb/moz-gdb/lib/00658c727e962a43/system/lib/libdvm.so
#3  0x7df02030 in _JNIEnv::GetObjectArrayElement (this=0x82702a78, array=0x1d4007f5, index=2)
    at /home/morbo/android-ndk-r8e/platforms/android-9/arch-arm/usr/include/jni.h:875
#4  0x7f08de72 in webrtc::videocapturemodule::DeviceInfoAndroid::CreateCapabilityMap (this=0x8a6f31c0, 
    deviceUniqueIdUTF8=0x8c1ffb88 "Camera 1, Facing front, Orientation 270")
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc:242
#5  0x7f08b7b4 in webrtc::videocapturemodule::DeviceInfoImpl::NumberOfCapabilities (this=0x8a6f31c0, 
    deviceUniqueIdUTF8=0x8c1ffb88 "Camera 1, Facing front, Orientation 270")
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/modules/video_capture/device_info_impl.cc:76
#6  0x7f126c36 in webrtc::ViEInputManager::NumberOfCaptureCapabilities (this=0x8a60f000, 
    device_unique_idUTF8=0x8c1ffb88 "Camera 1, Facing front, Orientation 270")
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_input_manager.cc:110
#7  0x7f1024b8 in webrtc::ViECaptureImpl::NumberOfCapabilities (this=0x8a8dae24, 
    unique_idUTF8=0x8c1ffb88 "Camera 1, Facing front, Orientation 270", unique_idUTF8Length=256)
    at /home/morbo/hg/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_capture_impl.cc:384
#8  0x7d4fc11e in mozilla::MediaEngineWebRTC::EnumerateVideoDevices (this=0x8a3d1b20, aVSources=0x8c1ffd2c)
    at /home/morbo/hg/mozilla-central/content/media/webrtc/MediaEngineWebRTC.cpp:186
#9  0x7d7136ac in mozilla::GetUserMediaRunnable::SelectDevice (this=0x8c6b3920)
    at /home/morbo/hg/mozilla-central/dom/media/MediaManager.cpp:687
#10 0x7d7133c8 in mozilla::GetUserMediaRunnable::Run (this=0x8c6b3920)
    at /home/morbo/hg/mozilla-central/dom/media/MediaManager.cpp:611
#11 0x7e8697c2 in nsThread::ProcessNextEvent (this=0x826fb970, mayWait=true, result=0x8c1ffe7f)
    at /home/morbo/hg/mozilla-central/xpcom/threads/nsThread.cpp:622
#12 0x7e804308 in NS_ProcessNextEvent (thread=0x826fb970, mayWait=true)
    at /home/morbo/hg/mozilla-central/objdir-android/xpcom/build/nsThreadUtils.cpp:238
#13 0x7e868a30 in nsThread::ThreadFunc (arg=0x826fb970) at /home/morbo/hg/mozilla-central/xpcom/threads/nsThread.cpp:250
#14 0x7797e650 in _pt_root (arg=0x886b5a80) at /home/morbo/hg/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:204
#15 0x40067a5c in __thread_entry () from /home/morbo/git/android-gdb/moz-gdb/lib/00658c727e962a43/system/lib/libc.so
#16 0x40067bd8 in pthread_create () from /home/morbo/git/android-gdb/moz-gdb/lib/00658c727e962a43/system/lib/libc.so
#17 0x00000000 in ?? ()
(Assignee)

Comment 28

4 years ago
http://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc#l215
http://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc#l240

Need to think a bit about why these particular callpaths are so long lived that the local references can't be GCed in time.
I ran on Valgrind on Nexus S (Android 4.0) but did not see any error
reports that looked in any way relevant, when doing reloads of
http://www.simpl.info/getusermedia.  That said, however, I couldn't
get it to crash when running natively (not-on-Valgrind).  So I don't
think this tells us anything.  If anyone has STR that make it crash on
Nexus S, let me know, so I can try that.
(Assignee)

Updated

4 years ago
Depends on: 918372
(Assignee)

Comment 30

4 years ago
It looks like the bug is that upon WebRTC-Android shutdown, the Android code is cleaning up after itself. But it also cleans up some global objects from SetAndroidObjects, which is only supposed to be called once at the very start. They are not recreated when you use WebRTC again, so when you try to use WebRTC a second time, things go boom.

Funnily enough I was defensive enough to actually null out the pointers I was garbage collecting, so it's a coincidence this ever worked. I guess there's a timing race between having the WebRTC stack shut down after the page closes, and restart when it's being reloaded, which is why the repro steps are also device-sensitive.
(Assignee)

Comment 31

4 years ago
Created attachment 807449 [details] [diff] [review]
Patch 1. Don't clean up global refs that are supposed to last a lifetime
Attachment #807449 - Flags: review?(blassey.bugs)
Attachment #807449 - Flags: review?(blassey.bugs) → review+
(Assignee)

Comment 32

4 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/a6f9e5a3c069
https://hg.mozilla.org/mozilla-central/rev/a6f9e5a3c069
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27

Updated

4 years ago
Blocks: 887693
Aaron - Can you find someone to manually verify this?
Flags: needinfo?(aaron.train)
Keywords: verifyme

Updated

4 years ago
Status: RESOLVED → VERIFIED
status-firefox25: --- → affected
status-firefox27: --- → verified
Flags: needinfo?(aaron.train)
Keywords: verifyme
gcp - can you nominate this for approval up to appropriate branches (aurora, beta)?
(Assignee)

Comment 36

4 years ago
Comment on attachment 807449 [details] [diff] [review]
Patch 1. Don't clean up global refs that are supposed to last a lifetime

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Android WebRTC
User impact if declined: Potential crash every 2nd or later time WebRTC is used, depending in timing.
Testing completed (on m-c, etc.): verified on m-c
Risk to taking this patch (and alternatives if risky): Absolute worst case it adds a small memory leak.
String or IDL/UUID changes made by this patch: NA
Attachment #807449 - Flags: approval-mozilla-beta?
Attachment #807449 - Flags: approval-mozilla-aurora?
Attachment #807449 - Flags: approval-mozilla-beta?
Attachment #807449 - Flags: approval-mozilla-beta+
Attachment #807449 - Flags: approval-mozilla-aurora?
Attachment #807449 - Flags: approval-mozilla-aurora+
Keywords: verifyme
https://hg.mozilla.org/releases/mozilla-aurora/rev/4baf5c9bfeeb
https://hg.mozilla.org/releases/mozilla-beta/rev/3e3dddbf79fc
status-firefox24: affected → wontfix
status-firefox25: affected → fixed
status-firefox26: affected → fixed
You need to log in before you can comment on or make changes to this bug.