Crash in [@ mozilla::ipc::FatalError | mozilla::ipc::IProtocol::HandleFatalError | IPC::ParamTraits<JSStructuredCloneData>::Write | IPC::ParamTraits<mozilla::SerializedStructuredCloneBuffer>::Write | IPC::ParamTraits<mozilla::dom::indexedDB::Serialized...
Categories
(Core :: Storage: IndexedDB, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox131 | --- | affected |
People
(Reporter: release-mgmt-account-bot, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/eb65bf98-c117-48df-b3f6-e7df00240719
MOZ_CRASH Reason: MOZ_CRASH(IPC FatalError in the parent process!)
Top 10 frames of crashing thread:
0 libxul.so mozilla::ipc::FatalError ipc/glue/ProtocolUtils.cpp:203
1 libxul.so mozilla::ipc::IProtocol::HandleFatalError ipc/glue/ProtocolUtils.cpp:403
2 libxul.so IPC::ParamTraits<JSStructuredCloneData>::Write ipc/glue/SerializedStructuredCloneBuffer.cpp:25
3 libxul.so IPC::WriteParam<JSStructuredCloneData const&> ipc/chromium/src/chrome/common/ipc_message_utils.h:445
3 libxul.so IPC::ParamTraits<mozilla::SerializedStructuredCloneBuffer>::Write ipc/glue/SerializedStructuredCloneBuffer.h:77
3 libxul.so IPC::WriteParam<mozilla::SerializedStructuredCloneBuffer const&> ipc/chromium/src/chrome/common/ipc_message_utils.h:445
3 libxul.so IPC::ParamTraits<mozilla::dom::indexedDB::SerializedStructuredCloneReadInfo>::Write ipc/ipdl/PBackgroundIDBSharedTypes.cpp:526
4 libxul.so IPC::WriteParam<mozilla::dom::indexedDB::SerializedStructuredCloneReadInfo const&> ipc/chromium/src/chrome/common/ipc_message_utils.h:445
4 libxul.so IPC::ParamTraits<mozilla::dom::indexedDB::ObjectStoreGetResponse>::Write ipc/ipdl/PBackgroundIDBRequest.cpp:169
4 libxul.so IPC::WriteParam<mozilla::dom::indexedDB::ObjectStoreGetResponse const&> ipc/chromium/src/chrome/common/ipc_message_utils.h:445
By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:
- First crash report: 2024-07-16
- Process type: Parent
- Is startup crash: No
- Has user comments: No
- Is null crash: Yes - all crashes happened on null or near null memory address
| Reporter | ||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Storage: IndexedDB' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•2 years ago
|
||
Comment 3•2 years ago
|
||
Okay, so this sounds like a case of file descriptor exhaustion, given that we're on Linux. Unfortunately the crash I don't think will give us any useful context about who was using all the file descriptors (although there are 97 memory regions with "memfd" in them that look like filename: "memfd:mozilla-ipc (deleted)" although not all are exactly the same.
The crash histogram does show there was a spike in the notable past, but I'd assume this is correlated with something that was addressed since the spike went away, although I'll make this P3/S3 in case the spike returns, etc. Given that this crash is an effect more than a cause, I'm going to mark this stalled, noting that bug 1885077 would be the way to help address fd exhaustion if IndexedDB is somehow responsible for the fd exhaustion. I only see 2 IDB I/O threads in the parent process, so if it was IDB, backpressure would be appropriate there.
| Reporter | ||
Comment 4•1 year ago
|
||
Closing because no crashes reported for 12 weeks.
Comment 5•1 year ago
|
||
Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.
Description
•