Not new but ~80 crashes/day.

Crash report: https://crash-stats.mozilla.org/report/index/706664f1-cb92-42bd-b6f9-56e950210324

MOZ_CRASH Reason: MOZ_CRASH()

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 xul.dll NS_DebugBreak xpcom/base/nsDebugImpl.cpp:435
2 xul.dll nsDebugImpl::Abort xpcom/base/nsDebugImpl.cpp:134
3 xul.dll XPTC__InvokebyIndex 
4  @0x21c32d21a8f 
5 xul.dll trunc 
6 xul.dll trunc 
7 xul.dll static XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1142
8 xul.dll XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:925
9 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:520

A majority of these are on history: blocking, so clearing browsing history on shutdown.

Looking at telemetry for FX_SANITIZE_HISTORY https://mzl.la/3ucntAG there is indeed an increase in value in Firefox 85.
That's something we should investigate since it may be related with this increase in crashes, clearing history became suddently more expensive.

We can exclude SQLite updates here, because those happened in 86, as well as most of the notifications work Daisuke made that also landed in 86.

A few things that landed in 85 that we should investigate as potential causes:
https://bugzilla.mozilla.org/show_bug.cgi?id=1677408
https://bugzilla.mozilla.org/show_bug.cgi?id=1677969
https://bugzilla.mozilla.org/show_bug.cgi?id=1677977
https://bugzilla.mozilla.org/show_bug.cgi?id=1595483
https://bugzilla.mozilla.org/show_bug.cgi?id=1680977

This was also the first release with browser.toolbars.bookmarks.2h2020, not sure if it matters, one thing is that it could have increased the numer of times the toolbar view is visible.

I'm mostly annotating things to investigate for now, no clear indication of a culprit yet.

clearing history also includes:
Ci.nsIClearDataService.CLEAR_HISTORY |
Ci.nsIClearDataService.CLEAR_SESSION_HISTORY |
Ci.nsIClearDataService.CLEAR_CONTENT_BLOCKING_RECORDS

and it also includes principal collector, that was also modified in 85 in https://bugzilla.mozilla.org/show_bug.cgi?id=1675018

Johann, could bug 1675018 have made history clearing take a longer time?
I'm investigating the Places side, but since the measurement happens as whole, it could be one of these other parts.

301 to Paul, though I'm not sure if he has more time to investigate. I agree that shutdown crashes from sanitization are bad, but realistically we have to make sanitization more comprehensive. It would be great if we could make it more efficient, but I think that the real solution is still a progress dialog indicating to the user that something is happening.

This is an async shutdown crash. Based on the crash reports, looks like only 10-15% is happening in clearing history on release currently. The majority of async shutdown blocking is happening in formdata. Needs more investigation.

We should add more reporting/logging during clearing history so we can better identify what's causing shutdown to be blocked. We could split it into multiple steps.

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 20 desktop browser crashes on release

:mak, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit auto_nag documentation.