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

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto] (PTO)]

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

Top 10 frames of crashing thread:

0 libxul.so mozilla::dom::quota::QuotaObject::EnableQuotaCheck dom/quota/ActorsParent.cpp:3314
1 libxul.so mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:10965
2 libxul.so non-virtual thunk to mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp
3 libxul.so mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:12753
4 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1220
5 libxul.so <name omitted> xpcom/threads/nsThreadUtils.cpp:481
6 libxul.so mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:12826
7 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1220
8 libxul.so <name omitted> xpcom/threads/nsThreadUtils.cpp:481
9 libxul.so 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.

Comment 1

[Jens Stutte [:jstutte]]

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

Comment 2

[Simon Giesecke [:sg] [he/him]]

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.

Comment 3

[Simon Giesecke [:sg] [he/him]]

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.

Comment 4

[Jan Varga [:janv]]

(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.

Comment 5

[Simon Giesecke [:sg] [he/him]]

Attachment: Bug 1620917 - Ensure a failure of StartTransactionOp is correctly handled on the resulting CommitOp. r=#dom-workers-and-storage

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/872d0f74da79
Ensure a failure of StartTransactionOp is correctly handled on the resulting CommitOp. r=dom-workers-and-storage-reviewers,janv

Comment 7

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/872d0f74da79

Comment 8

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

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