Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/c58f32ce-90d8-42a5-a2dc-8221b0211209

MOZ_CRASH Reason: MOZ_CRASH(OOM)

Top 10 frames of crashing thread:

0 xul.dll NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:616
1 xul.dll nsStringInputStream::SerializeInternal<mozilla::ipc::ChildToParentStreamActorManager> xpcom/io/nsStringStream.cpp:441
2 xul.dll nsStringInputStream::Serialize xpcom/io/nsStringStream.cpp:421
3 xul.dll static mozilla::ipc::InputStreamHelper::SerializeInputStream ipc/glue/InputStreamUtils.cpp:140
4 xul.dll nsMultiplexInputStream::SerializeInternal<mozilla::ipc::ChildToParentStreamActorManager> xpcom/io/nsMultiplexInputStream.cpp:985
5 xul.dll nsMultiplexInputStream::Serialize xpcom/io/nsMultiplexInputStream.cpp:963
6 xul.dll mozilla::ipc::`anonymous namespace'::SerializeInputStreamWithFdsChild<mozilla::dom::ContentChild> ipc/glue/IPCStreamUtils.cpp:52
7 xul.dll mozilla::ipc::AutoIPCStream::Serialize ipc/glue/IPCStreamUtils.cpp:403
8 xul.dll static mozilla::RemoteLazyInputStreamUtils::SerializeInputStream dom/file/ipc/RemoteLazyInputStreamUtils.cpp:98
9 xul.dll mozilla::dom::IPCBlobUtils::SerializeInternal<mozilla::dom::ContentChild> dom/file/ipc/IPCBlobUtils.cpp:133

There are 3 crashes (from 2 installations) in nightly 97 with buildid 20211209093228. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1740797.

[1] https://hg.mozilla.org/mozilla-central/rev?node=7ea7f84500f7

This crash signature is on other branches, but it doesn't seem to have shown up much on Nightly until recently, which is worrying. We'll probably want to keep an eye on beta, as I'd expect any big memory problems will show up in greater volume there.

This is probably a new OOM signature brought about because folks were sending large blobs over IPC, and previously we would not OOM but instead have a race (the race fixed by bug 1740797). The fix in that bug was intentionally simple in order to avoid any extra complexity, but is inefficient in this case, as we do an unnecessary copy of the buffer's string when serializing it over IPC.

We can improve the situation here by having the serialization implementation for the blob's DataOwnerAdapter not forward to the inner nsStringInputStream and instead perform the forwarding to pipe serialization directly. (https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/file/MemoryBlobImpl.h#127)

Assigning to myself, though I won't be able to get to it until the new year.

This is looking scary-high on Beta96 :(

Comment on attachment 9257563 [details]
Bug 1745373 - Avoid copying blob payload when serializing over IPC, r=mccr8

Beta/Release Uplift Approval Request

• User impact if declined: Increased risk of OOM crashes when serializing large blobs over IPC
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch makes a fairly straightforward change to avoid a copy in a fairly safe way, so I am not too worried about any fallout from the change
• String changes made/needed: None

https://hg.mozilla.org/mozilla-central/rev/98a667d2813d

Comment on attachment 9257563 [details]
Bug 1745373 - Avoid copying blob payload when serializing over IPC, r=mccr8

Approved for 96.0rc2 and 91.5esr.

https://hg.mozilla.org/releases/mozilla-esr91/rev/28571c2eb962

https://hg.mozilla.org/releases/mozilla-release/rev/3e17bdd001de