Well, if we hang on nsThreadManager::Shutdown, that means we're past the (sync) [nsThreadManager::CancelBackgroundDelayedRunnables]https://searchfox.org/mozilla-central/rev/759872688df15a5d6ab305ffe39d90450590bfec/xpcom/build/XPCOMInit.cpp#624] already, so I don't see how bug 1695580 could be the direct cause of these hangs. But looking at [the report](https://crash-stats.mozilla.org/report/index/500b3371-f6b6-4e1f-9d9f-315900210411#allthreads) in comment 0, *BackgroundThreadPool #18* is blocked on a mutex in nsTimer::Cancel, presumably [here](https://hg.mozilla.org/mozilla-central/file/69df44c2f2348552017d105e1e8a703cc48dae8c/xpcom/threads/nsTimerImpl.cpp#l401). I see this pattern in other 89 crashes for this signature too. Bug 1704159 looks related, with a similar pattern for its 89 crashes. It seems likely that bug 1695580 has regressed something here. Could bug 1683404 be related too? nsTimerImpl::Shutdown() happens before nsThreadManager::Shutdown() and we've clearly caught a timer being interacted with while doing nsThreadManager::Shutdown(). My main questions are, What timer is this -- is it one from a DelayedRunnable? If so, how did we slip by nsThreadManager::CancelBackgroundDelayedRunnables()? The only hole I can see in CancelBackgroundDelayedRunnables logic atm is if something creates a background TaskQueue *after* CancelBackgroundDelayedRunnables. If a DelayedDispatch is then done on that TaskQueue, we'd dispatch a runnable to clean that up during [TaskQueue::BeginShutdown()](https://searchfox.org/mozilla-central/rev/759872688df15a5d6ab305ffe39d90450590bfec/xpcom/threads/TaskQueue.cpp#163) instead, but for background TaskQueues this happens *after* [nsTimerImpl::Shutdown()](https://searchfox.org/mozilla-central/rev/759872688df15a5d6ab305ffe39d90450590bfec/xpcom/build/XPCOMInit.cpp#630,653). I'm not sure how this case should behave, but I can try to verify this by inserting some TaskQueue creations and delayed dispatches locally. I can also plug this hole and hope that it gives us more info.
Bug 1704391 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Well, if we hang on nsThreadManager::Shutdown, that means we're past the (sync) [nsThreadManager::CancelBackgroundDelayedRunnables](https://searchfox.org/mozilla-central/rev/759872688df15a5d6ab305ffe39d90450590bfec/xpcom/build/XPCOMInit.cpp#624) already, so I don't see how bug 1695580 could be the direct cause of these hangs. But looking at [the report](https://crash-stats.mozilla.org/report/index/500b3371-f6b6-4e1f-9d9f-315900210411#allthreads) in comment 0, *BackgroundThreadPool #18* is blocked on a mutex in nsTimer::Cancel, presumably [here](https://hg.mozilla.org/mozilla-central/file/69df44c2f2348552017d105e1e8a703cc48dae8c/xpcom/threads/nsTimerImpl.cpp#l401). I see this pattern in other 89 crashes for this signature too. Bug 1704159 looks related, with a similar pattern for its 89 crashes. It seems likely that bug 1695580 has regressed something here. Could bug 1683404 be related too? nsTimerImpl::Shutdown() happens before nsThreadManager::Shutdown() and we've clearly caught a timer being interacted with while doing nsThreadManager::Shutdown(). My main questions are, What timer is this -- is it one from a DelayedRunnable? If so, how did we slip by nsThreadManager::CancelBackgroundDelayedRunnables()? The only hole I can see in CancelBackgroundDelayedRunnables logic atm is if something creates a background TaskQueue *after* CancelBackgroundDelayedRunnables. If a DelayedDispatch is then done on that TaskQueue, we'd dispatch a runnable to clean that up during [TaskQueue::BeginShutdown()](https://searchfox.org/mozilla-central/rev/759872688df15a5d6ab305ffe39d90450590bfec/xpcom/threads/TaskQueue.cpp#163) instead, but for background TaskQueues this happens *after* [nsTimerImpl::Shutdown()](https://searchfox.org/mozilla-central/rev/759872688df15a5d6ab305ffe39d90450590bfec/xpcom/build/XPCOMInit.cpp#630,653). I'm not sure how this case should behave, but I can try to verify this by inserting some TaskQueue creations and delayed dispatches locally. I can also plug this hole and hope that it gives us more info.