At some point, we weren't leaking anything in the content process, but I guess whatever patch got us to that point did not reduce the leak threshold, so at some point a leak was introduced. Fortunately, it is just a single nsTArray_base. I don't see this on release, so I think it was introduced in 57. I'll try to bisect it on treeherder. I tried to use XPCOM_MEM_LOG_CLASSES but I got a fatal assert almost immediately.

Bisecting through m-c on TreeHerder, it was this push that introduced the nsTArray leak: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=b4c1ad9565ee9d00d96501c4a83083daf25c1413&filter-searchStr=linux%20x64%20debug%20mochitest Oddly, on some earlier pushes, including one as late as "Wed Sep 6, 2:24:33." there was a larger leak involving some cookie stuff! But then it got fixed briefly, then the nsTArray leak started. (We really need to reduce the leak threshold to zero...)

It looks like bug 1390044 caused this. Specifically, this changeset: https://hg.mozilla.org/mozilla-central/rev/665ea291fce4

Is this the thing mrbkap just fixed.

I can't find the bug now.

smaug is referring to bug 1401412 which does ensure that we destroy an nsTArray before XPCOM shutdown instead of after. Andrew, can you see if that changeset fixes this?

It does look like this leak has gone away, thanks!