1462168 - Report numbers of toplevel actors in about:memory (or somewhere)

Status: RESOLVED FIXED

(Core :: IPC, enhancement, P2)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Bug 1461875 comment #2 suggests that we may be leaking toplevel IPC actors in some circumstances, or at least allocating a large enough number of them that we should understand why.

(It's possible that those could be some other stream-type Unix-domain sockets, but that's something else we don't have data to answer at present.  One thing I can rule out are the one-shot response sockets used by the sandbox file broker: those are SOCK_SEQPACKET, not SOCK_STREAM.)

It looks like the best place to do this is in MessageChannel: it has the actor name, and it also knows when the transport is cross-process, and it already has a memory reporter.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Writing this down here for future reference in case it's relevant: PStreamFilter looks suspicious here; see bug 1255894, and especially the Part 10 patch which makes it a top-level actor instead of managed by PBackground (which has a per-thread singleton).  If I'm following the code correctly, each StreamFilter object[*] has its own message transport (socketpair, on Unix).

That would explain transient spikes in fd usage, but not the reports I've seen of large numbers of stream sockets when idle, unless there's a leak somewhere.


[*] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/StreamFilter

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Note to self: It might also be useful to record a per-class high-water mark.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1462168 - Report number of IPC channels in about:memory.

This adds an about:memory branch, "ipc-channels", which counts
cross-process IPC channels (ProcessLink, IPC::Channel) broken down by
the top-level IPDL actor name; these use OS resources which may be
limited (file descriptors on Linux and Mac).  Intra-process use of IPC
(ThreadLink) is not counted.

The maximum channel count for each actor type is reported in another
branch, "ipc-channels-peak".  This might be useful if there are
conditions that cause transient fd exhaustion, for example.

This patch also works around a problem where MessageChannel was trying
to register reporters too early in child processes, and failing.

Review commit: https://reviewboard.mozilla.org/r/258276/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258276/

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Example (parent):

26 (100.0%) -- ipc-channels
├───8 (30.77%) ── PBackgroundParent
├───3 (11.54%) ── PCompositorManagerParent
├───3 (11.54%) ── PContentParent
├───3 (11.54%) ── PImageBridgeParent
├───3 (11.54%) ── PProcessHangMonitorParent
├───3 (11.54%) ── PProfilerParent
└───3 (11.54%) ── PVRManagerParent

35 (100.0%) -- ipc-channels-peak
├──11 (31.43%) ── PBackgroundParent
├───4 (11.43%) ── PCompositorManagerParent
├───4 (11.43%) ── PContentParent
├───4 (11.43%) ── PImageBridgeParent
├───4 (11.43%) ── PProcessHangMonitorParent
├───4 (11.43%) ── PProfilerParent
└───4 (11.43%) ── PVRManagerParent

Partial example (content):

9 (100.0%) -- ipc-channels
├──3 (33.33%) ── PBackgroundChild
├──1 (11.11%) ── PCompositorManagerChild
├──1 (11.11%) ── PContentChild
├──1 (11.11%) ── PImageBridgeChild
├──1 (11.11%) ── PProcessHangMonitorChild
├──1 (11.11%) ── PProfilerChild
└──1 (11.11%) ── PVRManagerChild

Comment 5

[Andrew McCreight [:mccr8]]

Comment on attachment 8993567 [details]
Bug 1462168 - Report number of IPC channels in about:memory.

https://reviewboard.mozilla.org/r/258276/#review265484

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81d6e0ddef07
Report number of IPC channels in about:memory. r=mccr8

Comment 7

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

https://hg.mozilla.org/mozilla-central/rev/81d6e0ddef07