1090544 - Better memory leak tooling for the devtools tests

Status: NEW

(DevTools :: General, defect)

Description

[Eddy Bruel [:ejpbruel]]

The current state of our memory leak tooling for the devtools tests is a sad state of affairs. The problem seems to be that we have no way to guarantee that the things we cleaned up in our cleanup function are actually gone by the time the memory leak detector gets to run, and this makes our memory leak detection inherently racy.

This has been a recurring source of pain for me, and other people on the team as well. What's worse, nobody seems to know how to really solve these issues. I've ran into tons of intermittent memory leaks while trying to get the debugger tests to run with e10s enabled. There is no obvious cause for these leaks, and the proposed solutions I've heard so far amount to doing random tweaks until the test works, ranging from adding aritifical delays or doing forcible gcs. None of these solutions solve the actual underlying problem, so even if they do work, there is no guarantee that the test won't still leak on inbound or try.

Still worse, sometimes a test works fine when run individually, but causes memory leaks when run sequentially with other tests. Figuring all this out constitutes a huge time sink. Quite frankly, I think its bizarre that many of our tests turn out to be so fragile in practice. We need to do better.

At this point, I'm not sure what would be a better way to detect memory leaks in our test, so the main purpose of this bug is to open up a discussion. Mike tells me there have been some efforts in the past to improve the situation, but I don't know what the outcome of that effort was, and have been unable to find the corresponding bug. Perhaps Panos can help here?