Crash in [@ mozilla::dom::quota::DirectoryLockImpl::~DirectoryLockImpl]
Categories
(Core :: Storage: Quota Manager, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | unaffected |
firefox131 | --- | unaffected |
firefox132 | --- | unaffected |
firefox133 | --- | fixed |
People
(Reporter: gsvelto, Assigned: janv)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(3 files, 1 obsolete file)
Crash report: https://crash-stats.mozilla.org/report/index/91126153-b87a-41b3-919c-171b70241006
MOZ_CRASH Reason:
MOZ_DIAGNOSTIC_ASSERT(!mRegistered)
Top 10 frames:
0 xul.dll mozilla::dom::quota::DirectoryLockImpl::~DirectoryLockImpl() dom/quota/DirectoryLockImpl.cpp:72
1 xul.dll mozilla::dom::quota::DirectoryLockImpl::Release() dom/quota/DirectoryLockImpl.h:185
2 xul.dll mozilla::RefPtrTraits<mozilla::dom::quota::DirectoryLock>::Release(mozilla::d... mfbt/RefPtr.h:49
2 xul.dll RefPtr<mozilla::dom::quota::DirectoryLock>::ConstRemovingRefPtrTraits<mozilla... mfbt/RefPtr.h:409
2 xul.dll RefPtr<mozilla::dom::quota::DirectoryLock>::~RefPtr() mfbt/RefPtr.h:80
2 xul.dll mozilla::dom::(anonymous namespace)::PrepareDatastoreOp::~PrepareDatastoreOp() dom/localstorage/ActorsParent.cpp:6578
2 xul.dll mozilla::dom::(anonymous namespace)::PrepareDatastoreOp::~PrepareDatastoreOp() dom/localstorage/ActorsParent.cpp:6573
3 xul.dll mozilla::Runnable::Release() xpcom/threads/nsThreadUtils.cpp:66
3 xul.dll mozilla::InputStreamLengthHelper::Release() storage/mozStorageConnection.cpp:778
4 xul.dll mozilla::RefPtrTraits<mozilla::dom::(anonymous namespace)::LSRequestBase>::Re... dom/localstorage/ActorsParent.cpp:3448
This appears to be a different issue from the older bug 1903387. It only affects Windows for the time being, but this could just be because we have more Windows users on nightly than on the other platforms.
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Comment 1•1 month ago
|
||
It seems this started happening after bug 1919788.
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Comment 2•1 month ago
|
||
We know that in some cases a directory lock isn't being dropped in
PrepareDatastoreOp::Cleanup, but it's unclear if it's mDirectoryLock or
mExtraDirectoryLock. This patch should help identify that.
Assignee | ||
Comment 3•1 month ago
|
||
Assignee | ||
Comment 4•1 month ago
|
||
I think I found a code path which may be causing the assertion, working on a test and fix.
Updated•1 month ago
|
Updated•1 month ago
|
Assignee | ||
Comment 6•1 month ago
|
||
Assignee | ||
Comment 7•1 month ago
|
||
PrepareDatastoreOp::GetResponse is not called if there was an error, so the
transformation of the regular directory lock into the extra directory lock must
be done right after finding existing datastore.
Comment 9•1 month ago
|
||
bugherder |
Assignee | ||
Updated•1 month ago
|
Updated•1 month ago
|
Comment 10•1 month ago
|
||
bugherder |
Assignee | ||
Updated•1 month ago
|
Description
•