Regression in Firefox 85. crash-stats lists 150 crashes for 85 vs 2 for 84. ESR hast 9 for 78.7.0, 11 for 78.6.x, 1 for 78.5.x.

Jon, is this a signature change or a real regression?

Crash report: https://crash-stats.mozilla.org/report/index/5a1945b7-daa4-41e0-ae8d-952570210204

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0 XUL js::GCMarker::processMarkStackTop js/src/gc/Marking.cpp:2034
1 XUL js::GCMarker::markUntilBudgetExhausted js/src/gc/Marking.cpp:1798
2 XUL js::gc::GCRuntime::markUntilBudgetExhausted js/src/gc/GC.cpp:5626
3 XUL js::gc::GCRuntime::incrementalSlice js/src/gc/GC.cpp:6713
4 libmozglue.dylib mozilla::detail::MutexImpl::unlock mozglue/misc/Mutex_posix.cpp:121
5 XUL TelemetryHistogram::Accumulate toolkit/components/telemetry/core/TelemetryHistogram.cpp:2550
6 XUL FulfillMaybeWrappedPromise js/src/builtin/Promise.cpp:1347
7 XUL js::gcstats::Statistics::beginSlice js/src/gc/Statistics.cpp:1189
8 XUL js::gc::GCRuntime::gcCycle js/src/gc/GC.cpp:7169
9 XUL js::gc::GCRuntime::collect js/src/gc/GC.cpp:7403

These stacks are slightly garbled. They seem to be somewhere else with this snippet of "MutexImpl::unlock | TelemetryHistogram::Accumulate" inserted in the middle.

Mostly these are GCMarker::processMarkStackTop crashes and likely heap/memory corruption, so bug 719114.

Gabriele, maybe this is another instance of bug 1665411?

Also, as jonco pointed out, there's something bizarre about these signatures and stacks which might be worth a look.

(In reply to Andrew McCreight [:mccr8] from comment #2)

Gabriele, maybe this is another instance of bug 1665411?

I don't think so, there's no signs of UAF accesses and the crashes are happening on macOS 10.16/11. Bug 1665411 only seems to manifest itself up to 10.15. What worries me however is that the stacks seem to be all over the place: we seem to rely on stack-scanning for libxul which souldn't be happening. We should have been using CFI in there to get a high-quality stack trace; I'll open another bug for that.

Looks like bug 1687907 added mozilla::detail::MutexImpl::unlock to the socorro sentinels list so anything before that on the stack disappears from the signature.

We might want to revert that signature change so unreliable stack-scanning doesn't cause unrelated crashes to get merged under the same signature?

Not tracking on the basis that the recent spike looks like a signature change.

We are reaching RC and the crash volume is low, so wontfix 86.

Updating signature after bug 1692983.

Looking at crash addresses, on the latest set of crashes mostly suggests that these are memory corruption (bit flips) likely caused by faulty hardware.

Marking as stalled.