1524237 - Crash in mozilla::ipc::ProcessLink::SendMessage | IPC_Message_Name=PContent::Msg_SetClipboard on attempt to copy much text into the clipboard

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This bug is for crash report bp-5e257e8c-18d7-4fa1-84c0-f112b0190131.

Top 10 frames of crashing thread:

0 xul.dll mozilla::ipc::ProcessLink::SendMessage ipc/glue/MessageLink.cpp:152
1 xul.dll mozilla::ipc::MessageChannel::Send ipc/glue/MessageChannel.cpp:995
2 xul.dll mozilla::dom::PContentChild::SendSetClipboard ipc/ipdl/PContentChild.cpp:2711
3 xul.dll nsClipboardProxy::SetData widget/nsClipboardProxy.cpp:36
4 xul.dll static nsresult SelectionCopyHelper dom/base/nsCopySupport.cpp:269
5 xul.dll nsCopySupport::FireClipboardEvent dom/base/nsCopySupport.cpp:801
6 xul.dll nsClipboardCommand::DoCommand dom/base/nsGlobalWindowCommands.cpp:525
7 xul.dll nsControllerCommandTable::DoCommand dom/commandhandler/nsControllerCommandTable.cpp:140
8 xul.dll nsBaseCommandController::DoCommand dom/commandhandler/nsBaseCommandController.cpp:123
9 xul.dll nsresult nsXBLPrototypeHandler::DispatchXBLCommand dom/xbl/nsXBLPrototypeHandler.cpp:541

Reproduces on Ubuntu 16.10 (tested with 64.0 64-bit) and Windows 8.1 (latest Nightly 67.0a1 32-bit and 65.0 64-bit)

Steps to reproduce:

1. Open https://taskcluster-artifacts.net/HYfODDPwRwqqFSFf1QzG2w/0/public/logs/live_backing.log
2. Hit Ctrl+A (crashes on Linux, auto copy?)
3. Hit Ctrl+C

Linux crash report: bp-1f114fb3-f707-4239-8622-3a3ac0190131

Comment 1

[Rob Wu [:robwu]]

I reproduced this with bp-d1490658-2ef2-434a-8982-3cede0190629

STR:

1. Create a 64 MB file, e.g. python -c 'print("x x "*16777216)' > /tmp/quitebig.txt
2. Hit Ctrl-A. On Linux, selecting text puts the text on the primary clipboard.
3. If not on Linux, press Ctrl-C to put the text on the clipboard.

Expected:

• Text is selected, and put on the clipboard.
• Alternatively, the text is not put on the clipboard, but an error is reported to the global JS console / stderr.

Actual:

• Tab crashes.

Comment 3

[Rob Wu [:robwu]]

The issue is that there is an attempt to serialize the whole nsTransferable to send it over IPC. There used to be a file-based cache for large clipboard data (which results in a reasonably-sized IPC message), but that was disabled for content processes because opening files is not allowed in the content process (bug 1482540).

There is some more context on this cache and its behavior at https://bugzilla.mozilla.org/show_bug.cgi?id=1433030#c20 and the linked bugs.

To fix this bug without regressing on behavior (i.e. still being able to copy lots of data), the clipboard content should be shared separately from the main IPC message when it's too large.

Comment 5

[Chris Peterson [:cpeterson]]

Bug 1564196 comment 1 says this may be a regression from 2015 bug 1071562.

The 67 MB log file that crashed Firefox can be selected and copied in Chrome. Safari, however, won't even select the text.

Comment 7

[Gabriele Svelto [:gsvelto]]

Added a signature

Comment 8

[Stephen A Pohl [:spohl]]

Gian-Carlo, this is a P1 bug but currently doesn't have an owner. From what I can tell based on the crash reports, it affects all platforms. Would you be able to assign this to someone, or lower the priority to a P2? Thank you!

Comment 9

[Gian-Carlo Pascutto [:gcp]]

We won't get to this right away, but it definitely looks like something that should be on our radar.

Comment 11

[David Parks [:handyman]]

This is a copy-paste issue caused by the message size limitation in IPC.

A fix for this could use Shmems to pass the data instead of strings in IPCDataTransferData. The right nexus point for this decision appears to be nsContentUtils::TransferableToIPCTransferable, which already "promotes" C-strings to Shmems but uses nsStrings for wide strings. It could use the same "Shmem promotion" for wide-strings, and the other data types. In all cases, the decision should be based on message size, since allocating and copying to Shmem uses resources and time and is used to avoid this failure.

Comment 12

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Edgar, this may be interesting to you to consider for other recent related clipboard work.
(And I think we need to assess the severity/priority as well.)

Comment 13

[Marco Castelluccio [:marco]]

Edgar, given the low volume, should this be S3 instead of S2?

Comment 14

[Edgar Chen [:edgar]]

(In reply to Marco Castelluccio [:marco] from comment #13)

Edgar, given the low volume, should this be S3 instead of S2?

The volume is low, but quite easy to reproduce, so I am inclined to keep this S2.

Comment 15

[Edgar Chen [:edgar]]

Attachment: Bug 1524237 - Use Shmem for sending large string data in IPCDataTransfer;

Depends on D146074

Comment 16

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=353fb170648bfca4318f73bd29e472b75a3c5f8b

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0e46a4d44e2c
Use Shmem for sending large string data in IPCDataTransfer; r=NeilDeakin

Comment 19

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/0e46a4d44e2c

Comment 20

[Anca Soncutean, Desktop QA]

I’ve reproduced this signature crash with Fx 97.0a1 (2022-01-01) on Windows 10.
Verified fixed with Fx 103.0a1 (2022-06-07) and Fx 102.0b5 on Windows 10, macOS 12.1 and Ubuntu 20.04.