<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Updated

•

11 years ago

Whiteboard: [native-crash] → [native-crash][getUserMedia][android-gum-]

Comment 2

•

11 years ago

Steps in the duplicate bug above from ekr.

Eric Rescorla (:ekr)

Comment 3

•

11 years ago

I can reproduce this fairly reliably. If there is something simple you would like me to do, please LMK.

Comment 4

•

11 years ago

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

•

11 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)

Mark Finkle (:mfinkle) (use needinfo?)

Comment 6

•

11 years ago

(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: --- → ?

Updated

•

11 years ago

Assignee: nobody → gpascutto

tracking-fennec: ? → 24+

Assignee

Comment 7

•

11 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

•

11 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.

Comment 9

•

11 years ago

24 wont-fix?

Adam Roach [:abr]

Comment 10

•

11 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

•

11 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.

Eric Rescorla (:ekr)

Comment 12

•

11 years ago

I don't know if this helps, but on my Nexus 7, it's quite reliable. Perhaps some kind of clue...

Assignee

Comment 13

•

11 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.

Comment 14

•

11 years ago

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?

Comment 15

•

11 years ago

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

Comment 16

•

11 years ago

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

Comment 17

•

11 years ago

Attached file Test Case (Disable Permission Prompt When Running This) — Details

Comment 18

•

11 years ago

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)

Comment 19

•

11 years ago

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

•

11 years ago

Keywords: reproducible

Comment 20

•

11 years ago

Devices reproducible with so far: - Nexus 4 - Nexus 7 - Nexus 10 - Galaxy S4 Devices not reproducible so far: - Galaxy Nexus

Comment 21

•

11 years ago

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

Comment 22

•

11 years ago

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.

Comment 23

•

11 years ago

(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- > b34722130906 → bug 887277's signature

Comment 24

•

11 years ago

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

•

11 years ago

Blocks: 887227

Assignee

Comment 25

•

11 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

•

11 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

•

11 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

•

11 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.

Julian Seward [:jseward]

Comment 29

•

11 years ago

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

•

11 years ago

Depends on: 918372

Assignee

Comment 30

•

11 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.

Brad Lassey [:blassey] (use needinfo?)

Assignee

Comment 31

•

11 years ago

Attached patch Patch 1. Don't clean up global refs that are supposed to last a lifetime — Details — Splinter Review

Attachment #807449 - Flags: review?(blassey.bugs)

Updated

•

11 years ago

Attachment #807449 - Flags: review?(blassey.bugs) → review+

http://hg.mozilla.org/integration/mozilla-inbound/rev/a6f9e5a3c069

Assignee

Comment 32

•

11 years ago

Ryan VanderMeulen [:RyanVM]

Comment 33

•

11 years ago

https://hg.mozilla.org/mozilla-central/rev/a6f9e5a3c069

Status: NEW → RESOLVED

Closed: 11 years ago

Resolution: --- → FIXED

Target Milestone: --- → mozilla27

Updated

•

11 years ago

Blocks: 887693

Comment 34

•

11 years ago

Aaron - Can you find someone to manually verify this?

Flags: needinfo?(aaron.train)

Keywords: verifyme

Updated

•

11 years ago

Status: RESOLVED → VERIFIED

status-firefox25: --- → affected

status-firefox27: --- → verified

Flags: needinfo?(aaron.train)

Keywords: verifyme

Comment 35

•

11 years ago

gcp - can you nominate this for approval up to appropriate branches (aurora, beta)?