On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow <ge...@thunderbird.net> wrote:
> Hi all, I need some advice. > > I'm trying to enable Mochitest on debug builds of Thunderbird. It works > fine, except for the leak check, which finds a number of leaked windows > and docshells. Obviously we don't want to leak these things, but I can't > find what's holding onto them. > > I've ruled out a number of likely candidates and I'm quickly running out > of ideas. Can you offer any tips or tricks that might help? > > Here's an example log: > > https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267576044&repo=try-comm-central&lineNumber=8051 What this leak checker means is that a docshell or window was created while the test was running, but was not destroyed until after the test finished (and we ran a bunch of GCs and CCs). However, these docshells and windows don't show up in the leakcheck output, which means that they were cleaned up before we shut down. A typical cause for these is that there's some top level data structure, often in JS but it could be in C++, too, that keeps track of every docshell or window that is created, and does so by just adding a reference to it. When we start shutdown, the data structure gets torn down, and we don't leak things forever. One small tip is that if you look at the line after the "leaked until shutdown" message and you'll see something like this: [task 2019-09-20T03:42:16.942Z] 03:42:16 INFO - TEST-INFO | comm/calendar/test/browser/browser_calendarList.js | windows(s) leaked: [pid = 1155] [serial = 38], [pid = 1155] [serial = 36], [pid = 1155] [serial = 39], [pid = 1155] [serial = 37] The entries like "[pid = 1155] [serial = 38]" are the descriptors we use for windows (and docshells have a similar thing). If you search for "[pid = 1155] [serial = 38]" in the log, you can see where exactly each window was created and destroyed. Sometimes that can give a hint about what is going wrong. Like Emilio said, the best approach to fixing these leaks is going to be getting GC/CC logs from the point where it complains about the window being alive, and then you can figure out from there what is keeping the window alive, which may or may not point at what the leak is. In practice, doing all of this leak fixing is rather a big project by itself, so I'd recommend that you disable this leak checking in Thunderbird somehow, and then just try to get the rest of the debug tests up and running, and then maybe come back to it later. This leak checking is done in this file (by doing postprocessing of the browser log): testing/mochitest/leaks.py > > GL > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
