Crash in [@ mozilla::dom::quota::QuotaObject::EnableQuotaCheck]
Categories
(Core :: Storage: IndexedDB, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox74 | --- | wontfix |
firefox75 | --- | wontfix |
firefox76 | --- | fixed |
People
(Reporter: gsvelto, Assigned: sg)
Details
(Keywords: crash, csectype-nullptr)
Crash Data
Attachments
(1 file)
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•5 years ago
|
||
It seems more a problem within Indexed DB's handling of the mQuotaObject (or the DatabaseConnection
instance lifecycle itself).
Assignee | ||
Comment 2•5 years ago
|
||
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 | ||
Comment 3•5 years ago
|
||
So this might happen,
- either because
Database::DisableQuotaCheck->GetQuotaObjects
failed in theStartTransactionOp
, but still we get to running aCommitOp
Database::EnableQuotaCheck
is called more than once subsequently by one or moreCommitOp
s.
@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•5 years ago
|
||
(In reply to Simon Giesecke [:sg] [he/him] from comment #3)
So this might happen,
- either because
Database::DisableQuotaCheck->GetQuotaObjects
failed in theStartTransactionOp
, but still we get to running aCommitOp
This seems more likely. EnableQuotaChecks now need to handle previously failed DisableQuotaChecks call.
Assignee | ||
Comment 5•5 years ago
|
||
Comment 7•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Updated•5 years ago
|
Updated•5 years ago
|
Description
•