Nightly crashes in my Windows 7 VM when I'm doing similar steps as on bug 801551. It's not always crashing so you have to repeat the steps a couple of times. Steps: 1. Open Firefox and clear the caches 2. Open https://people.mozilla.com/~anarayanan/webrtc/gum_test.html 3. Click on Video (which should show that no hardware is available) 4. Reload the page and select Audio, stop it after some seconds 5. Click on Video again 6. Quit Firefox Crash report: bp-a5dade22-51ef-4508-b075-34bd22121016 0 msvcr100.dll abort f:\dd\vctools\crt_bld\self_x86\crt\src\abort.c:83 1 msvcr100.dll abort f:\dd\vctools\crt_bld\self_x86\crt\src\abort.c:83 2 msvcr100.dll _wassert f:\dd\vctools\crt_bld\self_x86\crt\src\assert.c:335 3 gkmedias.dll cubeb_destroy media/libcubeb/src/cubeb_winmm.c:241 4 xul.dll nsAudioStream::ShutdownLibrary content/media/nsAudioStream.cpp:379 5 xul.dll nsCycleCollector::CollectWhite xpcom/base/nsCycleCollector.cpp:2275 6 xul.dll nsCycleCollector::FinishCollection xpcom/base/nsCycleCollector.cpp:2781 7 xul.dll nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:2666 8 xul.dll nsCycleCollector::Shutdown xpcom/base/nsCycleCollector.cpp:2831 9 xul.dll nsCycleCollector_shutdown xpcom/base/nsCycleCollector.cpp:3188 10 xul.dll mozilla::ShutdownXPCOM xpcom/build/nsXPComInit.cpp:615 11 xul.dll ScopedXPCOMStartup::~ScopedXPCOMStartup toolkit/xre/nsAppRunner.cpp:1111 12 xul.dll XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:3879 13 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3933 14 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:105 15 firefox.exe __tmainCRTStartup crtexe.c:552 16 kernel32.dll BaseThreadInitThunk 17 ntdll.dll __RtlUserThreadStart 18 ntdll.dll _RtlUserThreadStart
Crash Signature: [@ cubeb_destroy]
Looks like it is somewhat related to the cycle collector. CC'ing Andrew.
Crash Signature: [@ cubeb_destroy] → [@ abort | abort | _wassert ]
This isn't really cycle collector related. During shutdown, cubeb_destroy is being called, and it is hitting a fatal assertion assert(ctx->active_streams == 0); So it is trying to destroy the cubeb while there are active streams, I guess. Probably some kind of wonkiness in shutdown code. This assertion was added in bug 742154.
This could be because in the WebRTC test we don't release a local mediastream correctly. So could be related to bug 798037.
Can't reproduce after trying a few times with an integrated webcam with nightly on Win 7 64-bit. On my machine, I am seeing the camera light shutoff on shutdown of firefox, so at least we know that piece works. I don't think it's related to bug 798037, as that relates to being able to release the camera through JS. This talks about the Firefox shutdown process. The stack also weirdly enough, doesn't show any evidence of WebRTC related modules, which is different than the first bug I found a while back.
Wait a second. This is bombing out on an assert, right? Are you testing on a debug build of Nightly? That might explain why I can't reproduce it.
I do not have a debug build on Windows. It's a standard nightly build. And whether if I enable the webcam in the VM or not I see the same behavior each time.
(In reply to Henrik Skupin (:whimboo) from comment #6) > I do not have a debug build on Windows. It's a standard nightly build. And > whether if I enable the webcam in the VM or not I see the same behavior each > time. Hmm....that changes things then if it's possible that it's happening without the webcam. I wonder if this is core video/audio bug. I'm sending it over there for one of those guys to take a look.
Component: WebRTC: Audio/Video → Video/Audio
QA Contact: jsmith
Looks like a shutdown/ordering issue in WebRTC. I can't reproduce it on Linux (with a similar check added to cubeb_alsa.c's cubeb_destroy), so I haven't investigated further.
Component: Video/Audio → WebRTC: Audio/Video
QA Contact: jsmith
The patch to bug 792175 will probably fix these shutdown issues. We'll need to try these again after it lands.
Whiteboard: [getUserMedia] → [getUserMedia] [blocking-gum+]
I'm going to hold testing of this until bug 792175 lands.
Created attachment 675761 [details] Testcase In the process of testing something else, I found a reproducible test case for this crash.
(In reply to Jason Smith [:jsmith] from comment #11) > Created attachment 675761 [details] > Testcase > > In the process of testing something else, I found a reproducible test case > for this crash. Oh btw for running this test case, STR: 1. Load the attached test case 2. Allow permissions for the video gUM call, followed by audio gUM call 3. Once the video and audio stream starts running, quit firefox Result - Firefox crashes
Not crashtest worthy - this happens during firefox shutdown.
(In reply to Jason Smith [:jsmith] from comment #13) > Not crashtest worthy - this happens during firefox shutdown. Huh? It's indeed helpful to have a test here. But it should most likely be a Mozmill test.
(In reply to Henrik Skupin (:whimboo) from comment #14) > (In reply to Jason Smith [:jsmith] from comment #13) > > Not crashtest worthy - this happens during firefox shutdown. > > Huh? It's indeed helpful to have a test here. But it should most likely be a > Mozmill test. Right. Not crashtest worthy, but it's worthy of a mozmill test.
Strongly related to leak and general shutdown issues.
Assignee: nobody → rjesup
Running the latest Nightly on Win7, this works for me.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Yeah, I can't reproduce either.
Status: RESOLVED → VERIFIED
Nils, do you think that this is something we should create a test for?
Yes, as we have nothing to verify resource release on FF shutdown I think it would be helpful to have one Mozmill test case which calls getUserMedia to get audio and video stream, and while holding on to that stream exits FF.
You need to log in before you can comment on or make changes to this bug.