1435961 - nsUrlClassifierDBService::Shutdown() blocks the shutdown of other components

Status: RESOLVED DUPLICATE of bug 1435343

(Core :: DOM: Core & HTML, defect, P3)

Description

[Andrea Marchesini [:baku]]

https://crash-stats.mozilla.com/report/index/abebf122-97e0-4c84-9927-f88ed0180205#allthreads

Here it seems that nsUrlClassifierDBService::Shutdown() blocks the main-thread dispatching SyncRunnable that doesn't return. Because this is done when xpcom-shutdown notification is received, this doesn't allow other components to receive the same notification, and, eventually, fx crashes.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

This appears to be due to using SyncRunnables/DISPATCH_SYNC from mainthread, probably because they need to wait for some other thread to do something during shutdown, and if they return from Observe the shutdown sequence will continue.

Instead, anything which needs to do other-thread actions or wait should use an AsyncShutdown blocker (nsIAsyncShutdownClient, etc) - you can see this  in action in C++ code in MediaManager.cpp.  Then you don't need to use a sync message from the shutdown observer/etc.

Comment 2

[Wayne Mery (:wsmwk)]

At the time that crash-stats stopped accepting Thunderbird crashes, this was #4 crash for Thunderbird 91.3.0, right up there with numerous other shutdown crashes

• shutdownhang | NtUserPeekMessage | _PeekMessage - bug 1643264, bug 1547541, bug 1306838
• shutdownhang | RtlAcquireSRWLockExclusive | mozilla::detail::RunnableFunction<T>::Run - bug 1630597
• shutdownhang | mozilla::TaskController::GetRunnableForMTTask | mozilla::AppWindow::ShowModal - (no bug)
• shutdownhang | NtCallbackReturn - bug 1749139

etc

Comment 3

[Wayne Mery (:wsmwk)]

#4 crash for 102.0.3

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to normal. However, the bug has the topcrash keyword.
:hsinyi, could you consider increasing the severity of this top-crash bug? If the crash isn't "top" anymore, could you drop the topcrash keyword?

For more information, please visit auto_nag documentation.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #4)

The severity field for this bug is set to normal. However, the bug has the topcrash keyword.
:hsinyi, could you consider increasing the severity of this top-crash bug? If the crash isn't "top" anymore, could you drop the topcrash keyword?

For more information, please visit auto_nag documentation.

Per comment 3, it's a topcrash for thunderbird. According to the triage guideline, I am not sure the "severity" flag is the best place to reflect that.

Jens, I admit that I didn't read through all the comments here and in https://bugzilla.mozilla.org/show_bug.cgi?id=1435343. But what's the difference between these two? The exact same crash signature is linked here and there.

Comment 6

[Jens Stutte [:jstutte]]

This bug wanted to talk about one special case that can cause this. I have not checked if this case is still in the reports, but we cannot really distinguish cases based on this signature, so I would keep all investigations in the other bug. If we find a better way to classify the crashes automatically, we might want to create new bugs. Finding this better way could be part of the investigations in bug 1435343.