#0 0x00007fffef3336fd in nanosleep () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fffef333594 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137 #2 0x00007ffff3ead617 in ah_crap_handler(int) (signum=signum@entry=11) at /home/morbo/hg/mozilla-central/toolkit/xre/nsSigHandlers.cpp:103 #3 0x00007ffff3ead657 in child_ah_crap_handler(int) (signum=11) at /home/morbo/hg/mozilla-central/toolkit/xre/nsSigHandlers.cpp:115 #4 0x00007ffff4dbf675 in AsmJSFaultHandler(int, siginfo_t*, void*) (signum=<optimized out>, info=0x7fffffffbbb0, context=0x7fffffffba80) at /home/morbo/hg/mozilla-central/js/src/asmjs/AsmJSSignalHandlers.cpp:1162 #5 0x00007ffff7bce8d0 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007ffff2d408fd in mozilla::MediaEngineRemoteVideoSource::Deallocate() (this=0x7fffc78fbfc0) at /home/morbo/hg/mozilla-central/dom/media/webrtc/MediaEngine.h:199 #7 0x00007ffff2d408fd in mozilla::MediaEngineRemoteVideoSource::Deallocate() (this=0x7fffc78fbfc0) at /home/morbo/hg/mozilla-central/dom/media/webrtc/MediaEngineRemoteVideoSource.cpp:139 #8 0x00007ffff2d41198 in mozilla::MediaEngineRemoteVideoSource::Shutdown() (this=0x7fffc78fbfc0) at /home/morbo/hg/mozilla-central/dom/media/webrtc/MediaEngineRemoteVideoSource.cpp:83 #9 0x00007ffff2d3cbee in mozilla::MediaEngineWebRTC::Shutdown() (this=0x7fffd6418840) at /home/morbo/hg/mozilla-central/dom/media/webrtc/MediaEngineWebRTC.cpp:342 #10 0x00007ffff2ba949e in mozilla::MediaManager::Shutdown() (this=this@entry=0x7fffd69b1980) at /home/morbo/hg/mozilla-central/dom/media/MediaManager.cpp:2602 #11 0x00007ffff2bb4c3f in mozilla::MediaManager::Observe(nsISupports*, char const*, char16_t const*) (this=0x7fffd69b1980, aSubject=0x0, aTopic=<optimized out>, aData=0x0) at /home/morbo/hg/mozilla-central/dom/media/MediaManager.cpp:2690 #12 0x00007ffff0d4e01c in nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) (this=0x7fffd968cd88, aSubject=aSubject@entry=0x0, aTopic=aTopic@entry=0x7ffff5384fdb "xpcom-will-shutdown", someData=someData@entry=0x0) at /home/morbo/hg/mozilla-central/xpcom/ds/nsObserverList.cpp:113 #13 0x00007ffff0d4e14a in nsObserverService::NotifyObservers(nsISupports*, char const*, char16_t const*) (this=0x7fffe50a4080, aSubject=aSubject@entry=0x0, aTopic=aTopic@entry=0x7ffff5384fdb "xpcom-will-shutdown", aSomeData=aSomeData@entry=0x0) at /home/morbo/hg/mozilla-central/xpcom/ds/nsObserverService.cpp:307 #14 0x00007ffff0dc76b0 in mozilla::ShutdownXPCOM(nsIServiceManager*) (aServMgr=0x0) at /home/morbo/hg/mozilla-central/xpcom/build/XPCOMInit.cpp:847 #15 0x00007ffff0dc805c in NS_ShutdownXPCOM(nsIServiceManager*) (aServMgr=<optimized out>) at /home/morbo/hg/mozilla-central/xpcom/build/XPCOMInit.cpp:799 #16 0x00007ffff3eab9e3 in XRE_TermEmbedding() () at /home/morbo/hg/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:209 #17 0x00007ffff11882ba in mozilla::ipc::ScopedXREEmbed::Stop() (this=0x7fffe5053a50) at /home/morbo/hg/mozilla-central/ipc/glue/ScopedXREEmbed.cpp:115 #18 0x00007ffff302c1b6 in mozilla::dom::ContentProcess::CleanUp() (this=<optimized out>) at /home/morbo/hg/mozilla-central/dom/ipc/ContentProcess.cpp:97 #19 0x00007ffff3eac968 in XRE_InitChildProcess(int, char**, mozilla::gmp::GMPLoader*) (aArgc=<optimized out>, aArgv=<optimized out>, aGMPLoader=<optimized out>) at /home/morbo/hg/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:627 #20 0x0000000000408d1b in content_process_main(int, char**) (argc=5, argv=0x7fffffffda98) at /home/morbo/hg/mozilla-central/ipc/app/../contentproc/plugin-container.cpp:237 #21 0x0000000000408daa in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /home/morbo/hg/mozilla-central/ipc/app/MozillaRuntimeMain.cpp:11 (gdb) up #1 0x00007fffef333594 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137 137 ../sysdeps/unix/sysv/linux/sleep.c: No such file or directory. (gdb) #2 0x00007ffff3ead617 in ah_crap_handler (signum=signum@entry=11) at /home/morbo/hg/mozilla-central/toolkit/xre/nsSigHandlers.cpp:103 103 sleep(_gdb_sleep_duration); (gdb) #3 0x00007ffff3ead657 in child_ah_crap_handler (signum=11) at /home/morbo/hg/mozilla-central/toolkit/xre/nsSigHandlers.cpp:115 115 ah_crap_handler(signum); (gdb) #4 0x00007ffff4dbf675 in AsmJSFaultHandler (signum=<optimized out>, info=0x7fffffffbbb0, context=0x7fffffffba80) at /home/morbo/hg/mozilla-central/js/src/asmjs/AsmJSSignalHandlers.cpp:1162 1162 sPrevSEGVHandler.sa_handler(signum); (gdb) #5 <signal handler called> (gdb) #6 0x00007ffff2d408fd in AssertIsOnOwningThread (this=0x7fffc78fbfc0) at /home/morbo/hg/mozilla-central/dom/media/webrtc/MediaEngine.h:199 199 MOZ_ASSERT(PR_GetCurrentThread() == mOwningThread);

No luck bisecting this, it must've been there for a week or two and it's intermittent.

So, the presence of content_process_main seems to indicate this is the main thread of the content process. The assertion that fails checks if Deallocate is called on the same thread that allocated the MediaSource. The Deallocate is on the main thread. I assume the allocate was on the MediaManger thread. So the bug is there that MediaManager Observed the xpcom-shutdown on the MainThread and then calls Shutdown on the backends in the main thread. Indeed: void MediaManager::Shutdown() { MOZ_ASSERT(NS_IsMainThread()); ... if (mBackend) { mBackend->Shutdown(); // ok to invoke multiple times } Conversely GetUserMediaTask has: void Run() { MOZ_ASSERT(!NS_IsMainThread()); if (mVideoDevice) { rv = mVideoDevice->Allocate(GetInvariant(mConstraints.mVideo), mPrefs); I think the bug is that Shutdown is called on the main thread?

This commit is exposing a long standing bug: https://hg.mozilla.org/mozilla-central/rev/075de7ffc645 Although the commit before may have helped provoke it: https://hg.mozilla.org/mozilla-central/rev/2f4ae4d923bc

https://dxr.mozilla.org/mozilla-central/rev/6c7c983bce46a460c2766fbdd73283f6d2b03a69/dom/media/MediaManager.cpp#2401 I think that seals the deal that the mBackend->Shutdown() should never have been on the main thread.

This is WebRTC I think, not playback?

jib: believe this is a dup of one you landed already

The async shutdown code I landed didn't change this. We're still calling it on main thread since forever: http://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp?rev=7ec70e0c6997&mark=2611-2611#2578

Aha. I think I have this fixed in the Webrtc.org 43 update code. I can cherry-pick the fix.

this is the patch we've been using in the werbrtc_43 update queue for a while

Comment on attachment 8685067 [details] [diff] [review] Shutdown MediaManager engines from the MediaManager thread Review of attachment 8685067 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/media/MediaManager.cpp @@ +2612,5 @@ > class ShutdownTask : public Task > { > public: > ShutdownTask(already_AddRefed<MediaEngine> aBackend, > + Mutex& aMutex, ShutdownTask already steals mBackend here [1] so we shouldn't need its mutex. Also, with recent changes (bug 1210852) the lone main-thread access of mBackend seems to be this code [1] handing it back to media thread. If we pass a MediaManager* this pointer instead, then I think we can remove mMutex altogether, since mBackend is now created and destroyed on media thread. [1] http://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp?rev=6f8a9e60e1a5&mark=2656-2656#2618

Removed the mutex entirely; mBackend is now only touched from the mediamanager threads

Comment on attachment 8688406 [details] [diff] [review] Shutdown MediaManager engines from the MediaManager thread Review of attachment 8688406 [details] [diff] [review]: ----------------------------------------------------------------- Works, but see comment. ::: dom/media/MediaManager.cpp @@ +2627,3 @@ > mozilla::ipc::BackgroundChild::CloseForCurrentThread(); > // must explicitly do this before dispatching the reply, since the reply may kill us with Stop() > + mManager->mBackend = nullptr; // last reference, will invoke Shutdown() again This comment has bothered me for a while, so I decided to find out if it is true, because, if it's true, and ~MediaEngine always calls Shutdown() then why call it twice (here and above)? Seems to me that if order is crucial somehow, we could move this line up to where we call Shutdown(), and have less code. So I looked, and it turns out some ~MediaEngine destructors call Shutdown() while others don't: http://mxr.mozilla.org/mozilla-central/search?string=~MediaEngine Specifically, ~MediaEngineTabVideoSource and ~MediaEngineDefaultAudioSource don't, while the others do. These seem like bugs, and maybe poor design because it causes them. It also makes me wonder, why the Shutdown function was broken out to begin with. It suggests some reason, which might be important to remember, otherwise we should remove it IMHO, to avoid such doubt.

Add ~MediaEngineDefaultVideoSource and ~MediaEngineCameraVideoSource to those that don't call Shutdown(). The latter makes sense since it's meant to be subclassed further.

[Tracking Requested - why for this release]: Causes crashing in debug build. Assertion failure: PR_GetCurrentThread() == mOwningThread, at /home/morbo/hg/mozilla-aurora/dom/media/webrtc/MediaEngine.h:199

Correction: seems the failing wrong-thread assertion was added in 44 [1]. Things still happened on the wrong thread earlier, but what the symptom of that is is less clear than comment 16. gcp speculated in #media that it might be the cause of Bug 1214675 comment 18. Gian-Carlo, do you still think this warrants uplift? To aurora at least? [1] http://hg.mozilla.org/mozilla-central/rev/075de7ffc645

Sorry, aurora is 44 now, so requesting uplift there only. 43 is "unaffected" in the sense that it didn't have the debug assert, and "wontfix" in the sense that things still happen on the wrong thread in 43.

Comment on attachment 8688406 [details] [diff] [review] Shutdown MediaManager engines from the MediaManager thread Approval Request Comment [Feature/regressing bug #]: Bug 1070216 http://hg.mozilla.org/mozilla-central/rev/075de7ffc645 [User impact if declined]: Shutdown crash in debug build with camera use. [Describe test coverage new/current, TreeHerder]: landed on m-c [Risks and why]: Low. MediaEngine should be shut down on media thread, because that's where it was created. [String/UUID change made/needed]: none.

When I test this patch on aurora locally, the assert crash is gone, but in its place I'm seeing other funkiness that I'm not seeing on central: [Parent 58537] WARNING: NS_ENSURE_SUCCESS(rv, NS_OK) failed with result 0x80004005: file /Users/Jan/moz/mozilla-aurora/dom/security/nsContentSecurityManager.cpp, line 430 [Parent 58537] WARNING: NS_ENSURE_SUCCESS(rv, NS_OK) failed with result 0x80004005: file /Users/Jan/moz/mozilla-aurora/dom/security/nsContentSecurityManager.cpp, line 430 ###!!! [Child][MessageChannel] Error: (msgtype=0x4400A5,name=PContent::Msg_ConsoleMessage) Channel closing: too late to send/recv, messages will be lost > [Child 58550] WARNING: MsgDropped in ContentChild: file /Users/Jan/moz/mozilla-aurora/dom/ipc/ContentChild.cpp, line 2190 > [Child 58550] WARNING: Audio Buffer is not full by the end of the callback.: 'Available() == 0 || mSampleWriteOffset == 0', file /Users/Jan/moz/mozilla-aurora/dom/media/AudioBufferUtils.h, line 87 > [Child 58550] WARNING: nsAppShell::Exit() called redundantly: file /Users/Jan/moz/mozilla-aurora/widget/cocoa/nsAppShell.mm, line 679 > [Child 58550] WARNING: NS_ENSURE_TRUE(context) failed: file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThread.cpp, line 769 > [Child 58550] WARNING: NS_ENSURE_TRUE(context) failed: file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThread.cpp, line 769 > [Child 58550] ###!!! ASSERTION: Failed Dispatch after xpcom-shutdown-threads: 'false', file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThread.cpp, line 584 > [Child 58550] ###!!! ASSERTION: Failed Dispatch after xpcom-shutdown-threads: 'false', file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThread.cpp, line 584 > [Child 58550] WARNING: '!mInitialized', file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThreadManager.cpp, line 244 > [Child 58550] WARNING: 'NS_FAILED(rv)', file /Users/Jan/moz/mozilla-aurora/xpcom/glue/nsThreadUtils.cpp, line 83 > [Child 58550] WARNING: 'NS_FAILED(rv)', file ../../dist/include/nsThreadUtils.h, line 77 > [Parent 58537] WARNING: waitpid failed pid:58550 errno:10: file /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/process_util_posix.cc, line 267 It's unmissable since I get two audible beeps in bash. This is followed by a crash in: explicit BaseAutoLock(T& aLock MOZ_GUARD_OBJECT_NOTIFIER_PARAM) : mLock(&aLock) { MOZ_GUARD_OBJECT_NOTIFIER_INIT; NS_ASSERTION(mLock, "null mutex"); => mLock->Lock(); } > MediaManager (36)#0 0x0000000100809371 in mozilla::BlockingResourceBase::CheckAcquire() at /Users/Jan/moz/mozilla-aurora/xpcom/glue/BlockingResourceBase.cpp:271 > #1 0x000000010080986f in mozilla::OffTheBooksMutex::Lock() at /Users/Jan/moz/mozilla-aurora/xpcom/glue/BlockingResourceBase.cpp:381 > #2 0x00000001006651ff in mozilla::BaseAutoLock<mozilla::Mutex>::BaseAutoLock(mozilla::Mutex&, mozilla::detail::GuardObjectNotifier&&) at /Users/Jan/moz/mozilla-aurora/obj-x86_64-apple-darwin12.2.1-debug/security/certverifier/../../dist/include/mozilla/Mutex.h:164 > #3 0x0000000100664135 in mozilla::BaseAutoLock<mozilla::Mutex>::BaseAutoLock(mozilla::Mutex&, mozilla::detail::GuardObjectNotifier&&) at /Users/Jan/moz/mozilla-aurora/obj-x86_64-apple-darwin12.2.1-debug/security/certverifier/../../dist/include/mozilla/Mutex.h:165 > #4 0x0000000103daead5 in mozilla::camera::CamerasChild::StopCapture(mozilla::camera::CaptureEngine, int) at /Users/Jan/moz/mozilla-aurora/dom/media/systemservices/CamerasChild.cpp:563 > #5 0x0000000103daea81 in mozilla::camera::StopCapture(mozilla::camera::CaptureEngine, int) at /Users/Jan/moz/mozilla-aurora/dom/media/systemservices/CamerasChild.cpp:557 > #6 0x0000000103e51860 in mozilla::MediaEngineRemoteVideoSource::Stop(mozilla::SourceMediaStream*, int) at /Users/Jan/moz/mozilla-aurora/dom/media/webrtc/MediaEngineRemoteVideoSource.cpp:220 > #7 0x0000000103c5ba56 in mozilla::MediaOperationTask::Run() at /Users/Jan/moz/mozilla-aurora/dom/media/MediaManager.cpp:315 > #8 0x0000000100e2d6c0 in MessageLoop::RunTask(Task*) at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/message_loop.cc:364 > #9 0x0000000100e2dc3f in MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/message_loop.cc:372 > #10 0x0000000100e2de64 in MessageLoop::DoWork() at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/message_loop.cc:459 > #11 0x0000000100f0271e in mozilla::ipc::DoWorkRunnable::Run() at /Users/Jan/moz/mozilla-aurora/ipc/glue/MessagePump.cpp:220 > #12 0x00000001007afce3 in nsThread::ProcessNextEvent(bool, bool*) at /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThread.cpp:964 > #13 0x000000010083adf7 in NS_ProcessNextEvent(nsIThread*, bool) at /Users/Jan/moz/mozilla-aurora/xpcom/glue/nsThreadUtils.cpp:297 > #14 0x0000000100f02fc0 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) at /Users/Jan/moz/mozilla-aurora/ipc/glue/MessagePump.cpp:355 > #15 0x0000000100e2d5a5 in MessageLoop::RunInternal() at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/message_loop.cc:234 > #16 0x0000000100e2d4b5 in MessageLoop::RunHandler() at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/message_loop.cc:227 > #17 0x0000000100e2d45d in MessageLoop::Run() at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/message_loop.cc:201 > #18 0x0000000100e529e9 in base::Thread::ThreadMain() at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/thread.cc:172 > #19 0x0000000100e53c2c in ThreadFunc(void*) at /Users/Jan/moz/mozilla-aurora/ipc/chromium/src/base/platform_thread_posix.cc:39 > #20 0x00007fff86d07899 in _pthread_body () > #21 0x00007fff86d0772a in _pthread_start () > #22 0x00007fff86d0bfc9 in thread_start () gcp, does this ring any bells?

That looks like the thing I was trying to debug before I hit this bug :-)

Is it much work to bisect where this got fixed on central?

I can't get mozregression to work anymore these days. Are others having that problem?

Jib, do you want me to wait until the you guys root cause the assert you ran into in comment 20? If you can file a different bug to track it, then I can approve this aurora uplift request. Please let me know.

Tracked for 44 since this might lead to a shutdown crash.

(In reply to Ritu Kothari (:ritu) from comment #24) > If you can file a different bug to track it, then I can > approve this aurora uplift request. Please let me know. Filed as Bug 1227407.

Comment on attachment 8688406 [details] [diff] [review] Shutdown MediaManager engines from the MediaManager thread Fixes a potential shutdown crash, has been in Nightly for a few days, seems safe to uplift to Aurora44.

(In reply to Carsten Book [:Tomcat] from comment #28) > https://hg.mozilla.org/releases/mozilla-aurora/rev/439a07e5ddca sorry had to back this out from aurora for causing memory leaks like https://treeherder.mozilla.org/logviewer.html#?job_id=1529770&repo=mozilla-aurora

After a fresh pull from aurora this morning (before the backout in comment 29) I can no longer reproduce the crash in comment 20. I still get the bash warnings and all that, but no crash. e.g. > [Child 89881] ###!!! ASSERTION: Failed Dispatch after xpcom-shutdown-threads: 'false', file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThread.cpp, line 584 > [Child 89881] ###!!! ASSERTION: Failed Dispatch after xpcom-shutdown-threads: 'false', file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThread.cpp, line 584 > > ###!!! [Child][MessageChannel] Error: (msgtype=0x4400CC,name=PContent::Msg_RecordingDeviceEvents) Closed channel: cannot send/recv > > [Child 89881] WARNING: MsgDropped in ContentChild: file /Users/Jan/moz/mozilla-aurora/dom/ipc/ContentChild.cpp, line 2190 > [Child 89881] WARNING: '!mMainThread', file /Users/Jan/moz/mozilla-aurora/xpcom/threads/nsThreadManager.cpp, line 295 > [Child 89881] WARNING: 'NS_FAILED(rv)', file /Users/Jan/moz/mozilla-aurora/xpcom/glue/nsThreadUtils.cpp, line 191 > [Child 89881] ###!!! ASSERTION: Failed NS_DispatchToMainThread() in shutdown; leaking: 'false', file /Users/Jan/moz/mozilla-aurora/xpcom/glue/nsThreadUtils.cpp, line 192 > [Child 89881] WARNING: Extra shutdown CC: 'i < NORMAL_SHUTDOWN_COLLECTIONS', file /Users/Jan/moz/mozilla-aurora/xpcom/base/nsCycleCollector.cpp, line 3557 > nsStringStats > => mAllocCount: 28857 > => mReallocCount: 2419 > => mFreeCount: 28857 > => mShareCount: 53786 > => mAdoptCount: 4119 > => mAdoptFreeCount: 4119 > => Process ID: 89881, Thread ID: 140735234535424 i.e. hardly the prettiest shutdown but it works. It does leak though: == BloatView: ALL (cumulative) LEAK STATISTICS, tab process 89916 |<----------------Class--------------->|<-----Bytes------>|<----Objects---->| | | Per-Inst Leaked| Total Rem| 0 |TOTAL | 17 5904| 5858258 49| 17 |AsyncTransactionTrackersHolder | 72 72| 30 1| 76 |CompositorChild | 880 880| 1 1| 78 |CondVar | 40 160| 280 4| 132 |DoWorkRunnable | 40 40| 23 1| 224 |IPC::Channel | 16 32| 8 2| 265 |MediaManager | 496 496| 1 1| 278 |MessagePump | 16 32| 26 2| 284 |Mutex | 32 128| 917 4| 305 |PCompositorChild | 776 776| 1 1| 311 |PImageBridgeChild | 920 920| 1 1| 362 |RefCountedMonitor | 80 160| 6 2| 363 |RefCountedTask | 16 64| 12 4| 404 |ShutdownBlocker | 40 40| 1 1| 413 |StoreRef | 16 32| 8 2| 464 |WaitableEventKernel | 96 192| 30 2| 469 |WeakReference<MessageListener> | 16 32| 373 2| 497 |base::Thread | 48 96| 4 2| 538 |ipc::MessageChannel | 512 1024| 6 2| 859 |nsRunnable | 24 24| 5975 1| 933 |nsTArray_base | 8 80| 1023767 10| 941 |nsThread | 256 512| 25 2| 946 |nsTimerImpl | 112 112| 792 1| nsTraceRefcnt::DumpStatistics: 1014 entries

Filed Bug 1228064 for the leak.

Is there a chance comment 29 is an otherwise white-listed PCompositorChild leak? See bug 1228064 comment 1.

That error in comment 29 reports things that leak in excess of the CompositorChild and ImageBridgeChild leaks. EG a DoWorkRunnable, a MediaManager, etc. Now, if you are adding things that would be leaked by CompositorChild or ImageBridgeChild, then the white list could be extended.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #23) > I can't get mozregression to work anymore these days. Are others having that > problem? pip install -U mozregression

Approval Request Comment: See bug 1228064 comment 7. [Risks and why]: We believe the 5 patches (Bug 1227407, Bug 1216972 and Bug 1218799, as outlined in bug 1228064 comment 5) collectively fix the 30 second hang, debug assert-crash and leak that plagued the new shutdown behavior in trunk for a while, and that aurora is better off using this approach than what it currently has, which exhibits at least the debug crash, maybe more. Worst case it still crashes on shutdown, but it is much less likely with these patches, and we have not seen any sign of trouble with them. 1 of the patches are in this bug, which already has a+, but bounced, and needs the others to fix it.

Jib, I a+ 3 patches from bug 1216972 and 1 patch from bug 1227407. The patch on this bug was already a+. Please let me know if I missed anything.

That's all of them. Thanks. You're doing the actual landing of them?

(In reply to Jan-Ivar Bruaroey [:jib] from comment #37) > That's all of them. Thanks. You're doing the actual landing of them? Ok. Thanks for the confirmation. Nope a sheriff will do it. Re-directing NI to Tomcat/KWierso.