Closed Bug 1767514 Opened 7 months ago Closed 6 months ago

Support large numbers of fds in a single message

Categories

(Core :: IPC, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
102 Branch
Tracking Status
firefox102 --- fixed

People

(Reporter: nika, Assigned: nika)

References

(Blocks 1 open bug)

Details

Crash Data

Attachments

(3 files)

Currently there is a hard limit of 200 handles attached to a single message, which generally is not a problem. This bug is tracking allowing this limit to be exceeded, by splitting up messages containing large numbers of fds into multiple sendmsg calls, and stitching them together on the receiving side.

This is done by splitting messages with large numbers of handles into multiple
sendmsg calls, each of which contains less than the maximum number of
transferred handles per-message, and stitching the message back together on the
receiving side. Most of the work on the receiving side was already handled by
the IPC::Channel code, so the work required was only to ensure we could split
the handle list up when sending.

This is made possible by part 1, which made it possible to send more messages
using IPC::Channel. A limit is still in place, however it is now substantially
higher, hopefully making it effectively unlimited for practical purposes.

Depends on D145391

Pushed by nlayzell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/62befea29e73
Part 1: Decouple the IPC::Message max handle count and the number of FDs supported by IPC::Channel, r=ipc-reviewers,jld
https://hg.mozilla.org/integration/autoland/rev/53ebc3f919ba
Part 2: Increase the attached handle limit for IPC Messages, r=ipc-reviewers,jld

Backed out for causing mochitest failures on browser_fullscreen_warning.js

Flags: needinfo?(nika)

[Child 1557, IPC I/O Child] WARNING: Message needs unreceived descriptors channel:1006b0040 message-type:3932222 header()->num_handles:13 num_fds:0 fds_i:0:

And the failures are all macOS, which is known to have some odd behavior around fd-passing (e.g., the sender has to hold the fds open until after they're received… or at least that used to be the case and we have code to work around it; and there was a weird edge case around almost-full socket buffers).

See Also: → 1768292
See Also: → 1768297
Regressions: 1768293

Poking around at this a bit, I think I've figured out that 3932222 is Msg_RegisterStringBundles on PContent (https://searchfox.org/mozilla-central/rev/c7183440fe8ad391e2ab2e990229dd85fac318d3/dom/ipc/PContent.ipdl#717). (on a side note, the message really ought to include msg->name() somewhere, but I digress). This lines up somewhat as it's a message being passed an array of FDs, which could easily have length 13. This is sent fairly early during startup as well (https://searchfox.org/mozilla-central/rev/c7183440fe8ad391e2ab2e990229dd85fac318d3/dom/ipc/ContentParent.cpp#3050), which lines up somewhat with the "WARNING: build ID mismatch false alarm" log message being emitted soon after.

It's quite surprising we'd be failing so early, as we wouldn't have had a chance to send some unexpected message with a large number of file descriptors which would need to be split into multiple sendmsg calls, so I would expect us to have actually done the exact same IPC calls now as we did previously.

I genuinely have no idea what could've changed to cause this breakage right now, but I suppose I'll come back to this later.

Flags: needinfo?(nika)
Flags: needinfo?(nika)
Blocks: 1757802
Blocks: 1769504

Before this change, we wouldn't re-try sending fds if the first attempt
to send them failed, meaning that some fds wouldn't arrive if there was
any error sending (e.g. because the send buffer was full, which
is more common on macOS).

This new approach ensures we don't record that we've sent the fds until
the message is marked as successful, and should avoid the macOS errors.

Depends on D145392

I ended up finding what I think the issue is

Flags: needinfo?(nika)
Pushed by nlayzell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/344ac1cc234f
Part 1: Decouple the IPC::Message max handle count and the number of FDs supported by IPC::Channel, r=ipc-reviewers,jld
https://hg.mozilla.org/integration/autoland/rev/f3c916fcf9fe
Part 2: Increase the attached handle limit for IPC Messages, r=ipc-reviewers,jld
https://hg.mozilla.org/integration/autoland/rev/bc0432d9dd95
Part 3: Retry sending fds if sendmsg fails, r=ipc-reviewers,jld
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch

Copying crash signatures from duplicate bugs.

Crash Signature: [@ mozilla::ipc::FatalError | mozilla::ipc::IProtocol::HandleFatalError | IPC::ParamTraits<mozilla::ipc::DataPipeReceiverStreamParams>::Read]
You need to log in before you can comment on or make changes to this bug.