1116261 - StoreRef leaks in child process with e10s

Status: RESOLVED WORKSFORME

(Core :: IPC, defect)

Description

[Andrew McCreight [:mccr8]]

Once the compositor-related leaks (bug 1065536) are fixed, then we're still leaking a couple of StoreRef in the child process.  If you add RevocableStore, then you'll see that we're also leaking a few of those, in both the child and parent processes.

Comment 1

[Andrew McCreight [:mccr8]]

Attachment: Add more MOZ_COUNT_CTOR for various revocable store stuff etc.

With this added, the child process shows leaks of ChannelImpl, IPC::Channel, RevocableStore, ScopedRunnableMethodFactory and StoreRef. I stopped pulling the yarn off the sweater at that point.

The parent process only shows a leak of RevocableStore, which is odd because we don't seem to ever directly allocate RevocableStore, and I thought I'd annotated all of its child classes.

Comment 2

[Andrew McCreight [:mccr8]]

This doesn't look like it is a fixed-size leak.  When you just open and close the browser, you leak about 3 of these, but in an e10s M4 run we're leaking 151.  That's still a small leak, but from comment 1, we're leaking other stuff, so it isn't clear exactly how much is leaking.  The best path forward here might be looking into e10s LSan runs, which should give a better overview of exactly how much Chromium IPC stuff we leak.

Comment 3

[Andrew McCreight [:mccr8]]

I think this is covered by some of the other IPC XPCOM leak checking I have added. At this point, there are only two leaking StoreRefs, one from CompositorChild and one from ImageBridgeChild, which have their own bugs.