1455106 - Fix memory reporting for IPC shared memory

Status: NEW

(Core :: IPC, enhancement, P2)

Description

[Jed Davis [:jld] (on leave until 08-31)]

IPC shared memory seems to have some hooks for tracking the total amount of shared memory allocated and mapped, but it also seems to be broken: on my browser the “mapped” value looks vaguely reasonable but the “allocated” value is 0, and the last time I checked on this the level of brokenness varied by platform.

It would probably help to clean up all the shared memory classes (bug 1454819), because the last time I dug into the code it looked like the hooks were weirdly split between levels of no-longer-user abstraction, and that might be why things are broken.  (Keep in mind that SharedMemoryBasic has clients other than ipc::Shmem.)

We may also want to track the number of shared memory items that {exist, are mapped, have fds open if Unix} separately from total size; see also bug 1453735.  On that topic, The_8472 pointed out on IRC that Linux has a limit of 64k memory areas; we don't seem to be at risk of running into that in non-leaky operation, but it's a finite resource that might be leaked.

Comment 1

[Jed Davis [:jld] (on leave until 08-31)]

This came up recently on Matrix #ipc:mozilla.org and we've found a few things:

1. SharedMemoryBasic_mach has a typo where it calls Mapped instead of Created, so the “allocated” size is always zero and the “mapped” size is increased twice but decreased once (i.e., everything appears as a leak and the mapped size can increase to absurd values)
2. Unmapped is called only on destruction, not unmap, so a map-unmap-map cycle should also cause false-alarm leaks… but an assertion I added for that didn't fire in a full Try run, so that case may not happen currently (at least with the mozilla:: classes; maybe it does for direct use of base::SharedMemory)
3. The “allocated” metric is weird, because it accounts memory to the process that created it, so a process that only receives shared memory will have 0 allocated but (in the general case) non-zero mapped. More interestingly, if a segment is destroyed by the process that created it while other processes still hold references, it wouldn't be “allocated” anywhere but it would still occupy resources.