Crash in [@ mozilla::dom::indexedDB::(anonymous namespace)::Cursor::SendResponseInternal]
Categories
(Core :: Storage: IndexedDB, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | unaffected |
firefox72 | --- | fixed |
People
(Reporter: marcia, Assigned: sg)
Details
(Keywords: crash, regression)
Crash Data
This bug is for crash report bp-af225479-c6e7-4c12-b6d0-9fa670191115.
Seen while looking at macOS specific nightly crashes - crashes started in 20191114214957: https://bit.ly/2Qm7dw8. All have MOZ_CRASH(Should never get here!)
Possible regression range based on build id: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2f19e7b646e0a52fa855b75c868f0a3f3a990ad3&tochange=88db9bea4580df16dc444668f8c2cddbb3414318
Top 10 frames of crashing thread:
0 XUL mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:15311
1 XUL mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:25741
2 XUL mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp:22177
3 XUL mozilla::dom::indexedDB:: dom/indexedDB/ActorsParent.cpp
4 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1250
5 XUL NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
6 XUL mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:333
7 XUL MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
8 XUL nsThread::ThreadFunc xpcom/threads/nsThread.cpp:458
9 libnss3.dylib _pt_root nsprpub/pr/src/pthreads/ptthread.c:201
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
I think I have an idea why this might happen with preloading cursors. When we return from https://searchfox.org/mozilla-central/rev/cac340f10816707e91c46db6d285f80259420f07/dom/indexedDB/ActorsParent.cpp#25956 for an error when processing extra responses, mFiles
might be non-empty but the transaction is not invalidated.
For the time being, we should change https://searchfox.org/mozilla-central/rev/cac340f10816707e91c46db6d285f80259420f07/dom/indexedDB/ActorsParent.cpp#25737 to unconditionally clear mFiles
(we will always hit an assertion in SendResponseInternal
if mFiles
is non-empty after we initialized mResponse
with an nsresult
to indicate failure).
I am not sure how to reproduce this by a test case to be able to fix this closer to the cause.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Description
•