QM: Investigate why the storage connection is sometimes not closed in QuotaManager::~QuotaManager
Categories
(Core :: Storage: Quota Manager, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox75 | --- | fixed |
People
(Reporter: janv, Assigned: janv)
References
Details
Attachments
(2 files)
We found this issue in bug 1604005 and we need to do more investigation.
Assignee | ||
Comment 1•6 years ago
|
||
In general, QuotaManager::ShutdownStorage triggers flushing of not yet committed data to disk and closing of files correctly, so it is quite important that it runs before QuotaManager object is destroyed.
Assignee | ||
Comment 2•6 years ago
|
||
I think I know why this can happen, I'll describe it in next comment.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 3•6 years ago
•
|
||
I think the real problem is that we don't wait for StorageOperationBase objects to finish in QuotaManager::Shutdown before we schedule a runnable to QM I/O thread for calling QuotaManager::ShutdownStorage which closes the storage connection.
We need to add tracking of these objects, so we spin the event loop in QuotaManager::Shutdown until these objects are finished.
I'll try to create a patch for this.
Assignee | ||
Comment 4•5 years ago
|
||
These methods never return false, so they can be safely converted to return void.
Assignee | ||
Comment 5•5 years ago
|
||
Comment 7•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/177f23c6bc89
https://hg.mozilla.org/mozilla-central/rev/9793a4979340
Description
•