647133 - Intermittent leak of 316867 bytes during mochitest-a11y on win7 debug

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1301630202.1301634614.18502.gz
Rev3 WINNT 6.1 mozilla-central debug test mochitest-other on 2011/03/31 20:56:42 
s: talos-r3-w7-008

PROCESS-CRASH | Main app process exited normally | application crashed (minidump found)
Thread 0 (crashed)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 316867 bytes during test execution
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 129 instances of AtomImpl with size 20 bytes each (2580 bytes total)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of BackstagePass with size 24 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of Connection with size 112 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of DR_State with size 40 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of GenericFactory with size 16 bytes

The leak analyzer says

  chrome://mochitests/content/chrome/dom/ipc/tests/test_process_error.xul leaked 1 DOMWINDOW(s)

I read over this log several times but can't make any sense of it.  test_process_error.xul runs during mochitest-chrome, it appears, but no leak is reported from there.  I see firefox shutting down in the log between the two tests.  During mochitest-a11y, nothing related to this test should be running, AFAIK, so I don't understand the leak analyzer's conclusion.

I suspect there are two problems here
 - bug in the leak analyzer
 - real leak of something from the mochitest-a11y suite, apparently new

At any rate, this began on http://hg.mozilla.org/mozilla-central/rev/26463a06d0ca which was a backout of an ~DONTBUILD cset, and doesn't seem particularly related to earlier pushes, so is almost certainly a new intermittent.

Comment 1

[Phil Ringnalda (:philor)]

Yeah, the test_process_error.xul thing is a tbpl bug, the test intentionally does something that the simplistic leak analyzer thinks means it leaked.

Comment 2

[Trevor Saunders (:tbsaunde)]

seems to have gone away for seven months and is atleast partially a tbpl bug,  close as worksforme

Comment 3

[Phil Ringnalda (:philor)]

Luckily, you didn't actually close it, since coincidentally I have another one:

https://tbpl.mozilla.org/php/getParsedLog.php?id=7150060&tree=Mozilla-Inbound

(the tbpl thing has nothing at all to do with whether or not mochitest-a11y leaked, only to do with whether its "analyze the leak" link pointed to an individual test which leaked a domwindow, or to a test which hides the way it doesn't leak its domwindow)

Comment 4

[Phil Ringnalda (:philor)]

(As long as you keep hardly ever leaking, I'll just keep dropping them in here, though I fear someday we'll get one that actually stays around.)

https://tbpl.mozilla.org/php/getParsedLog.php?id=9036985&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=9053713&tree=Mozilla-Inbound

Comment 5

[Ed Morley [:emorley]]

Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that:
* Haven't changed in > 6months
* Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb}
* Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive.

I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases).

Sorry for the spam! Filter on: #FFA500