This is needed to detect regressions in content process leaks that are being fixed in bug 1035454. Otherwise, we can apparently crash and it won't report an error. There's some code around to detect this situation, but I guess it isn't working for content processes for some reason.

ted, is this something you could look at?

This may be a dupe of bug 831223, I can't quite tell. eg it looks like there is code in the test harness that is already set up to do this, it is just intentionally disabled due to Gecko-side flakiness.

Also it looks like this may have regressed in the last week. :( 16:00:52 INFO - WARNING | leakcheck | tab process: missing output line for total leaks! Either that or my patch messed it up somehow. https://tbpl.mozilla.org/?tree=Try&rev=4b24221af3b5

Contrast that to my push from the 21st, where the leak detector is working: https://tbpl.mozilla.org/?tree=Try&rev=32bf41cea397 18:07:28 WARNING - TEST-UNEXPECTED-FAIL | leakcheck | tab process: 591085 bytes leaked (ActiveElementManager, AsyncLatencyLogger, AsyncTransactionTrackersHolder, AtomImpl, BackstagePass, ...)

If content processes are crashing we ought to be printing an error and a stack to the log (and it looks like we are, from your link in comment 3). Am I missing something?

Yeah, I think this is actually trivial to fix on the test harness side of things: there's code to do this, it is just intentionally a warning not an error. I hadn't looked into the particulars of it before, sorry for the bother.

I think the "crashes aren't an error" stuff dates back to before we had the code to handle expected crashes in Mochitest.

Well, from bug 831223 it sounds like the problem is that content processes sometimes end up shutting down after the main process, so the leak check was actually running, but it showed up too late. I don't know what the current state of affairs is for the main process waiting for child process shut down. I imagine with e10s the content process may be doing more shutdown work than the child process.