Closed Bug 1116261 Opened 8 years ago Closed 7 years ago

StoreRef leaks in child process with e10s

Categories

(Core :: IPC, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s + ---

People

(Reporter: mccr8, Unassigned)

References

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 file)

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.
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.
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.
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P2]
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.