Broken out from bug 850670: (In reply to Phil Ringnalda (:philor) from bug 850670 comment #2) > The problem isn't just that "automationutils.processLeakLog()" returns too > many things, it's also that there are more classes of leak than just > "identified by the first five classes of object leaked." There are also > ... > * Things which are characterized by the first or last thing in the list of > leaked URLs looking significant to a human. If your DR_State-including leak > ends its list with http://127.0.0.1:8888/safebrowsing-dummy/newkey, that's > your leak, if your DR_State-including leak ends its list with some URL from > one of the last tests to run, or a chrome image, good luck with finding what > actually does characterize your leak. (In reply to Ed Morley [:edmorley UTC+0] from bug 850670 comment #4) > I agree this won't cover all of the classes of leaks, but I think we should > try and still aim for a 95% solution (by frequency of manual starring) as a > v1 :-) > ... > Regarding the leaked URLs output, afaik it's not actually in the leak logs > (it comes from > http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL. > cpp#301) so would have to be handled separately anyway. We'll need to: * Parse the test run log to look for the leaked URLs list (perhaps with some changes to the way we format it, to reduce the risk of false positives etc) * Decide how to combine this with the existing leaked objects message (or not combine, just display both?) (Or even just adding "Leaked URLs:" to the TBPL parser list, so we get them/some of them showing in the brief log)

Mass closing bugs with no activity in 2+ years. If this bug is important to you, please re-open.