681866 - Intermittent 3MB leak during OSX 64-bit mochitest-chrome (AsyncStatement, CalculateFrecencyFunction, BodyRule, BackstagePass, etc)

Status: RESOLVED DUPLICATE of bug 653080

(Core :: General, defect)

Comment 1

[Boris Zbarsky [:bzbarsky]]

I tried to star a bunch of failures on inbound just now with this bug, but the comments aren't ending up here....

Comment 2

[Boris Zbarsky [:bzbarsky]]

And this may be a duplicate of bug 653080.

Comment 3

[Phil Ringnalda (:philor)]

Typing a bug number in tbpl's comment form doesn't make it comment in bugs, only picking a suggestion when it suggests does (otherwise, it would be a pretty marvelous way to spam tens of thousands of bugs). And I'd really strongly recommend either http://tbpl.allizom.org/ if you like tinderbox-based with an extra two or three hour delay most of the time (but the benefit of having your stars also visible on tbpl.mozilla.org), or http://tbpl.allizom.org/?usebuildbot=1 if you'd rather not have the delay and don't mind only having your stars be visible on the two allizom.org flavors. That would be the reason you thought they were unstarred, and needed to be dealt with, when they had already been starred by people using the buildbot flavor of allizom 90 or 180 minutes before. Sucks to be us, don't it?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> only picking a suggestion when it suggests does

Well, how do I get it to suggest a new bug?  ;)

In any case, I assume there is a plan to make tbpl.mozilla.org work right (as in, make it identical to one of those other two things)?

Comment 5

[Phil Ringnalda (:philor)]

Suggestions come from (roughly) "TEST .*-FAIL | there's a filename here | blah" and tbpl then searches for bugs with [orange] in the whiteboard and the filename in the summary. So an enhancement bug to have tbpl suggest bugs for leaks would need to have automationutils.processLeakLog() output something which would uniquely identify a leak. In the case of this one, as far as I'm concerned, that's "browser-chrome plus 1 AsyncStatement plus a thousand-odd AtomImpls plus the 'analyze this leak' link saying that two to four tests leaked domwindows, starting with browser_inspector_registertools.js", but for other leaks is "any test suite, no domwindows and x number of Foo leaked" and for other leaks is "this URL at the start (or end) of the list of leaked URLs". I don't mean to be discouraging, I'd be delighted if you could propose a heuristic that would let us suggest leaks without just suggesting every leak and causing people to randomly choose one for things which are actually new leaks, which is what we had when we used to suggest based on "automationutils.processLeakLog", I just don't have any idea what such a heuristic could be given the variety of keys to identifying a leak.

The written-down part of making tbpl.mozilla.org usable is bug 669000, with a dash of bug 659724 and friends around the edges. I presume there are far more unwritten parts involving MoCo politics, but I'm lucky enough to only have to know about them by observing the effects they have on visible things, just like with gravity.