1157308 - Reduce the leak threshold for content processes in e10s again

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

The e10sification of GMP has landed, so the slowly growing leak from those tests should be gone now.

Here's a try run with the leak threshold disabled:
  https://treeherder.mozilla.org/#/jobs?repo=try&revision=f25a8f74af9a

I retriggered the largest leaks.  I'll have to look over what those leaks are, and I should also look at the situation for reftests, which have a separate leak threshold.

Comment 1

[Andrew McCreight [:mccr8]]

Bug 1157468 and bug 1157467 are together responsible for the current high water mark across all Mochitests, of 10133 bytes leaked.

Comment 2

[Andrew McCreight [:mccr8]]

64-bit of course needs a higher leak threshold.  640bit reftests seem to be at about 4400 bytes leaked.  e10s M2 is at 12008 bytes (probably in part due to bug 1157515).  e10s M4 is at 7320 bytes (also in part to the same bug).

Comment 3

[Andrew McCreight [:mccr8]]

On trunk right now, on 64-bit, the e10s m4 leak is 24041 bytes.

Comment 4

[Andrew McCreight [:mccr8]]

The leaks mentioned in comment 1 have been fixed now. The high water mark for mochitests is M4, at 7960 bytes. For reftests, it is 4392 bytes.

Comment 5

[Andrew McCreight [:mccr8]]

Attachment: part 1 - Reduce the leak threshold for content processes more.

try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f174f125567c

Comment 6

[Eric Rahm [:erahm]]

Comment on attachment 8611224 [details] [diff] [review]
part 1 - Reduce the leak threshold for content processes more.

Review of attachment 8611224 [details] [diff] [review]:
-----------------------------------------------------------------

r=me. Your patch title has "part 1" in it, are there more patches coming?

::: testing/mochitest/mochitest_options.py
@@ +722,2 @@
>              # GMP rarely gets a log, but when it does, it leaks a little.
>              "geckomediaplugin": 20000,

Is this still valid?

Comment 7

[Andrew McCreight [:mccr8]]

Attachment: part 2 - Reduce the content process leak limit on OS X.

We don't run e10s tests on OS X, but there are some regular Mochitests that run a child process. One of these was leaking intermittently, so I added this code to bump up the leak limit. However, this leak seems to have gone away in the mean time, so I think we can remove this.

Here's a try run with a bunch of retriggers of M3 which is where the leak was showing up before:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6792130eed58

I split this into a separate patch so it can be easily backed out if the leak is still there.

Comment 8

[Eric Rahm [:erahm]]

Comment on attachment 8611276 [details] [diff] [review]
part 2 - Reduce the content process leak limit on OS X.

Review of attachment 8611276 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

Comment 9

[Andrew McCreight [:mccr8]]

(In reply to Eric Rahm [:erahm] from comment #6)
> Is this still valid?

I looked at an M3 run none of the GMP processes produced a leak log. I don't know if it still leaks or not, but realistically we can't lower the leak threshold unless we're getting logs consistently.

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/eed2a8fd3e92
https://hg.mozilla.org/integration/mozilla-inbound/rev/be2d54f71b51

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/eed2a8fd3e92
https://hg.mozilla.org/integration/mozilla-inbound/rev/be2d54f71b51

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/eed2a8fd3e92
https://hg.mozilla.org/mozilla-central/rev/be2d54f71b51