1762908 - Crash in [@ mozilla::dom::quota::OriginInfo::LockedDecreaseUsage]

Status: NEW

(Core :: Storage: Quota Manager, defect, P2)

Description

[[:philipp]]

Crash report: https://crash-stats.mozilla.org/report/index/763f4ef1-2988-4090-9e2f-3e3680220404

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(isSome())

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::quota::OriginInfo::LockedDecreaseUsage dom/quota/ActorsParent.cpp:7244
1 xul.dll mozilla::dom::quota::QuotaManager::DecreaseUsageForClient dom/quota/ActorsParent.cpp:3934
2 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::DeleteFile dom/indexedDB/ActorsParent.cpp:5795
3 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::DeleteFile dom/indexedDB/ActorsParent.cpp:5812
4 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::RemoveDatabaseFilesAndDirectory dom/indexedDB/ActorsParent.cpp:5984
5 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::DeleteDatabaseOp::VersionChangeOp::Run dom/indexedDB/ActorsParent.cpp:17517
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1146
7 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:330
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:324
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306

this crash signature is newly popping up again since the firefox 98 release, and with the current 91esr as well.
so it might be a recent regression from one of the code changes going into 91.7.0esr:
https://hg.mozilla.org/releases/mozilla-esr91/pushloghtml?fromchange=FIREFOX_91_6_0esr_RELEASE&tochange=FIREFOX_91_7_0esr_RELEASE

Comment 1

[Jens Stutte [:jstutte]]

Jan, in 98 landed bug 1733054 but IIUC this has not been uplifted to ESR, yet?

Comment 2

[Jens Stutte [:jstutte]]

FWIW I transformed the pushlog into a buglist but I cannot see anything obvious.

Comment 3

[Jens Stutte [:jstutte]]

I cracked up a dump and it seems we fail on the line AssertNoUnderflow(mClientUsages[aClientType].value(), aSize);, more precise on the mClientUsages[aClientType].value() access. That would be the equivalent of the assert just one line above.

A search for mClientUsages[mClientType].value shows that in most other places we use mClientUsages[mClientType].valueOr(0). That seems slightly inconsistent?

Comment 4

[Marco Castelluccio [:marco]]

Given the low volume of the crash, should this be S3 instead of S2?

Comment 5

[Marco Castelluccio [:marco]]

(In reply to Marco Castelluccio [:marco] from comment #4)

Given the low volume of the crash, should this be S3 instead of S2?

Needinfo for the above ^

Comment 6

[Jan Varga [:janv]]

It looks like there are no such crashes for recent FF releases. Either the signature has changed or it's been fixed in some other bug.

Comment 7

[Jens Stutte [:jstutte]]

Signature changed. Volume seems lower for recent releases but not zero.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Most of the crashes are still from esr128 although we did see one from 141 currently. We do think Jan's recent changes should likely decrease the rate of this happening; we will keep an eye on this. It does seem like this is something that should be impossible but clearly is not in some rare cases, so we will keep this as a P2 for now because it should be on our shortlist to look into.

Comment 9

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

There are a smaller number of crashes from 143.0/144b/145a1, so still happening, but not as much as in 140 or ESR 128