Closed
Bug 1228937
Opened 9 years ago
Closed 6 years ago
"Assertion failure: gFactoryOps->IsEmpty()" with lots of deleteDatabase
Categories
(Core :: Storage: IndexedDB, defect, P5)
Core
Storage: IndexedDB
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox45 | --- | affected |
firefox-esr60 | --- | unaffected |
firefox65 | --- | unaffected |
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: assertion, testcase)
Attachments
(2 files)
Assertion failure: gFactoryOps->IsEmpty(), at dom/indexedDB/ActorsParent.cpp:12757
(Easier to reproduce with a debug+opt build from Tinderbox than with a local debug build?)
Reporter | ||
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
As sorta covered on bug 1246828 comment 12, either:
- Factory::ActorDestroy should stop trying to (synchronously) clean up when it hits zero live factories.
- FactoryOp::ActorDestroy should synchronously clean itself up
This is necessary because Factory manages the FactoryOps and they're all destroyed synchronously with no turns of the event loop in-between. Because the factory ops have the added complexity of their mDelayedOp mechanism, modifying factory may be the cleanest option. While it could use a runnable that waits on the gFactoryOps to complete, its data structures seem relatively minimal and so it might make sense to move their destruction to the IDB quota client shutdown since that's a reasonable shutdown boundary.
Comment 3•9 years ago
|
||
Andrew, thanks for this analysis!
Comment 4•9 years ago
|
||
(In reply to Andrew Sutherland [:asuth] from comment #2)
> As sorta covered on bug 1246828 comment 12, either:
> - Factory::ActorDestroy should stop trying to (synchronously) clean up when
> it hits zero live factories.
> - FactoryOp::ActorDestroy should synchronously clean itself up
>
> This is necessary because Factory manages the FactoryOps and they're all
> destroyed synchronously with no turns of the event loop in-between. Because
> the factory ops have the added complexity of their mDelayedOp mechanism,
> modifying factory may be the cleanest option. While it could use a runnable
> that waits on the gFactoryOps to complete, its data structures seem
> relatively minimal and so it might make sense to move their destruction to
> the IDB quota client shutdown since that's a reasonable shutdown boundary.
I fully agree, we had a synchronous cleanup in FactoryOp::ActoryDestroy(), but it was a huge pain in the ass, so we removed it. I'll try to move Factory::ActoryDestroy cleanup to the quota client shutdown.
Thanks again!.
Comment 6•8 years ago
|
||
Bug 1246828 is now fixed. Jesse, could you be so kind as to verify this is now fixed (Jan was telling me he had a hard time reproducing)?
Flags: needinfo?(jruderman)
Updated•7 years ago
|
Status: NEW → UNCONFIRMED
Ever confirmed: false
Priority: -- → P5
Assuming FIXED by bug 1246828 as per comment 5.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jruderman)
Resolution: --- → FIXED
Updated•6 years ago
|
status-firefox65:
--- → unaffected
status-firefox-esr60:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•