Closed Bug 1596785 Opened 5 years ago Closed 5 years ago

Crash in [@ mozilla::dom::indexedDB::(anonymous namespace)::Cursor::SendResponseInternal]

Categories

(Core :: Storage: IndexedDB, defect, P1)

Desktop
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 1597038
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: nobody → sgiesecke
Status: NEW → ASSIGNED

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.

Priority: -- → P1
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.