1706036 - Crash in [@ mozilla::ipc::MessageChannel::Send | mozilla::ipc::IProtocol::ChannelSend | IPC_Message_Name=PBackgroundLSSnapshot::Msg_CheckpointAndNotify]

Status: ASSIGNED

(Core :: Storage: localStorage & sessionStorage, defect, P3)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/d1861606-3627-46ff-904f-d53fc0210419

MOZ_CRASH Reason: MOZ_CRASH(IPC message size is too large)

Top 10 frames of crashing thread:

0 xul.dll mozilla::ipc::MessageChannel::Send ipc/glue/MessageChannel.cpp:969
1 xul.dll mozilla::ipc::IProtocol::ChannelSend ipc/glue/ProtocolUtils.cpp:528
2 xul.dll mozilla::dom::PBackgroundLSSnapshotChild::SendCheckpointAndNotify ipc/ipdl/PBackgroundLSSnapshotChild.cpp:123
3 xul.dll mozilla::dom::LSSnapshot::Checkpoint dom/localstorage/LSSnapshot.cpp:923
4 xul.dll mozilla::dom::LSSnapshot::Run dom/localstorage/LSSnapshot.cpp:1004
5 xul.dll mozilla::CycleCollectedJSContext::AfterProcessTask xpcom/base/CycleCollectedJSContext.cpp:470
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1196
7 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:310

It seems like under some circumstances local storage is sending an IPC message that's too large to handle and it's leading to this crash. The crash is happening on both Windows and macOS

Comment 1

[Jens Stutte [:jstutte]]

So we send an array of storage items that might be containing a) many items or b) big single items. In case a) we could split the array, case b) could only be handled on insert of new items (if we knew a suitable maximum size). It seems, that for now we do not care about any maximum during insert.

FWIW, the limit of an IPC message is 256 MB. And it seems we had a similar problem over in bug 1597211.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Copying crash signatures from duplicate bugs.

Comment 5

[Jens Stutte [:jstutte]]

Attachment: Bug 1706036 - Split big LSSnapshot lists when sent via Checkpoint. r?#dom-storage-reviewers

Comment 6

[Jens Stutte [:jstutte]]

Attachment: Bug 1706036 - Test with a checkpoint having a payload larger than IPC maximum message size. r?#dom-storage-reviewers

Comment 7

[Phabricator Automation]

Comment on attachment 9335945 [details]
Bug 1706036 - Test with a checkpoint having a payload larger than IPC maximum message size. r?#dom-storage-reviewers

Revision D179117 was moved to bug 1706035. Setting attachment 9335945 [details] to obsolete.

Comment 8

[Jan Varga [:janv]]

Attachment: Bug 1706036 - Use BigBuffer for sending potentially large array of LSWriteAndNotifyInfos; r=#dom-storage

Comment 9

[Jens Stutte [:jstutte]]

Looking at this I would probably favor 1 from [Jan's latest comment](https://phabricator.services.mozilla.com/D157648#6231532:

1. Use the write optimizer even when there are observers in other content processes

This can break some sites, so we would need to experiment on Nightly only and then allow it on Release only for some users ?

It is the easiest implementation option and I would hope breakage to be minimal. The attempt to make a test for this shows, that a site would need to do so many changes to entries within one check point that it is hard to believe another tab could rely on reacting on all of them. We will always get notified about the latest change, which seems fine to me.

Comment 10

[Jan Varga [:janv]]

Yeah, let's try to do it with an option to enable the old behavior if there are problems, so:

1. Add a new "always coalesce" code path.
2. Put it behind a pref
3. Enable the pref on Nightly only