Closed Bug 1620917 Opened 11 months ago Closed 10 months ago

Crash in [@ mozilla::dom::quota::QuotaObject::EnableQuotaCheck]


(Core :: Storage: IndexedDB, defect, P2)




Tracking Status
firefox-esr68 --- unaffected
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- fixed


(Reporter: gsvelto, Assigned: sg)


(Keywords: crash, csectype-nullptr)

Crash Data


(1 file)

This bug is for crash report bp-2b09e940-0672-47d8-913c-1ee380200306.

Top 10 frames of crashing thread:

0 mozilla::dom::quota::QuotaObject::EnableQuotaCheck dom/quota/ActorsParent.cpp:3314
1 mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:10965
2 non-virtual thunk to mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp
3 mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:12753
4 nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1220
5 <name omitted> xpcom/threads/nsThreadUtils.cpp:481
6 mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:12826
7 nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1220
8 <name omitted> xpcom/threads/nsThreadUtils.cpp:481
9 mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:302

This affects all platforms and even though I found it on a recent nightly it started a while ago. The oldest affect buildid I could find is 20200129093157. It looks like a NULL-pointer dereference of the QuotaObject.

It seems more a problem within Indexed DB's handling of the mQuotaObject (or the DatabaseConnection instance lifecycle itself).

Component: Storage: Quota Manager → Storage: IndexedDB

I guess this might be happening since Bug 1414737 was resolved on 2020-01-23. I don't think it's a regression, though, but previously this crashed already in DisableQuotaChecks and we never got into EnableQuotaChecks, after GetQuotaObjects failed.

Assignee: nobody → sgiesecke
Priority: -- → P2

So this might happen,

  • either because Database::DisableQuotaCheck->GetQuotaObjects failed in the StartTransactionOp, but still we get to running a CommitOp
  • Database::EnableQuotaCheck is called more than once subsequently by one or more CommitOps.

@janv: Is it possible to start a second cleanup transactions for the same database, before the other one committed? Since DisableQuotaCheck/EnableQuotaCheck store the quota object on the database rather than the transaction, this would explain the issue.

Flags: needinfo?(jvarga)

(In reply to Simon Giesecke [:sg] [he/him] from comment #3)

So this might happen,

  • either because Database::DisableQuotaCheck->GetQuotaObjects failed in the StartTransactionOp, but still we get to running a CommitOp

This seems more likely. EnableQuotaChecks now need to handle previously failed DisableQuotaChecks call.

Flags: needinfo?(jvarga)
Pushed by
Ensure a failure of StartTransactionOp is correctly handled on the resulting CommitOp. r=dom-workers-and-storage-reviewers,janv
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
You need to log in before you can comment on or make changes to this bug.