Nathan Froyd [:froydnj] Reporter
	Description • 8 years ago

In Nightly after the content process has crashed several times, about:memory says, among other things:

0 (100.0%) -- queued-ipc-messages
├──0 (100.0%) ── content-parent(???, pid=-1, closed channel, 0x7f0b57fff828, refcnt=1)
├──0 (100.0%) ── content-parent(???, pid=-1, closed channel, 0x7f0b6adb3828, refcnt=4)
├──0 (100.0%) ── content-parent(???, pid=-1, closed channel, 0x7f0b7b882828, refcnt=1)
├──0 (100.0%) ── content-parent(???, pid=-1, closed channel, 0x7f0b87075828, refcnt=2)
├──0 (100.0%) ── content-parent(???, pid=-1, closed channel, 0x7f0b943eb828, refcnt=1)
├──0 (100.0%) ── content-parent(???, pid=-1, closed channel, 0x7f0b96b9a828, refcnt=3)
└──0 (100.0%) ── content-parent(???, pid=-1, closed channel, 0x7f0b9dbf9828, refcnt=2)

The description string for this:

http://dxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#518

suggests that we are leaking ContentParent instances.  I think this might be similar to bug 1188056, but this is with e10s switched on, and this is definitely not about thumbnailing processes--at least, I don't think it is.

Some of these might be related to killing the content process with SIGTERM (which I had to do to get my computer out of swapdeath).

	Andrew Overholt [:overholt]
	Comment 1 • 8 years ago

I don't know how to categorize the urgency of this bug: super high, within a couple of months, backlog?

	Andrew McCreight [:mccr8]
	Comment 2 • 8 years ago

This isn't too surprising. B2G had a ton of parent process leaks when the children got killed. I think it is less important for desktop, because killing content processes is not part of standard operation. How important this is depends on how often a user might experience a content process crash.

	Nathan Froyd [:froydnj] Reporter
	Comment 3 • 8 years ago

(In reply to Andrew Overholt [:overholt] from comment #1)
> I don't know how to categorize the urgency of this bug: super high, within a
> couple of months, backlog?

My sense is that this is somewhere between "couple of months" and "backlog", unless we have reason to think people are keeping sessions open but encountering multiple content process crashes per session, even after we work on addressing content process crashes.

	Nathan Froyd [:froydnj] Reporter
	Comment 4 • 8 years ago

This might also become more urgent when we start doing multiple content processes, since that would (likely) increase the frequency of content process crashes (both from our bugs and from memory pressure).

	Andrew Overholt [:overholt]
	Comment 5 • 8 years ago

Thanks.

	The 8472
	Comment 6 • 7 years ago

I have e10s-multi enabled (3) child processes and not long after startup I'm seeing at least one channel leaked without any noticeable child process crash, so this might also happen due to normal process lifecycles, not just crashes.

0 (100.0%) -- queued-ipc-messages
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x1aa2c98f6f8, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=125732, open channel, 0x1a994cdf6f8, refcnt=149)
├──0 (100.0%) ── content-parent(Browser, pid=126856, open channel, 0x1a9a8fbb6f8, refcnt=123)
└──0 (100.0%) ── content-parent(Browser, pid=87424, open channel, 0x1a9e30e46f8, refcnt=149)

	Sylvestre Ledru [:Sylvestre]
	Comment 7 • 6 years ago

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

	Sylvestre Ledru [:Sylvestre]
	Comment 8 • 6 years ago

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

	Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧
	Comment 9 • 6 years ago

I tried reproducing this on Linux with `kill` (with both SIGTERM and SIGSEGV), and I can't reproduce it — I did sometimes see channels in queued-ipc-messages with pid=-1 and refcnt=1 immediately after killing content processes, but they didn't survive a CC (and they don't show up in a verbose CC log, either).

I also have dom.ipc.processCount set to 64 in this profile, so there should have been a few normally-terminated content processes from closing tabs as well.

If someone else can still reproduce this, a CC log for the parent process would be a good place to start.