731709 - browser_tabMatchesInAwesomebar.js reports leak when run in isolation

Status: RESOLVED WORKSFORME

(Testing :: Mochitest, defect)

Description

[Luke Wagner [:luke]]

An example is:

python _tests/testing/mochitest/runtests.py --browser-chrome --autorun --close-when-done --test-path=browser/base/content/test/browser_tabMatchesInAwesomebar.js

nsTraceRefcntImpl::DumpStatistics: 891 entries
TEST-PASS | automationutils.processLeakLog() | no leaks detected!
TEST-INFO | ShutdownLeaks | leaked 2 DOMWindow(s) and 1 DocShell(s) until shutdown

[browser/base/content/test/browser_tabMatchesInAwesomebar.js]
  2 window(s) [url = about:blank]
  1 docShell(s)

Inspecting the CC logs, there don't seem to be any live windows/docshells.  Also, BloatView doesn't show any leaks, so there seems to be a disconnect here.

Comment 1

[Luke Wagner [:luke]]

Another example is: browser/base/content/test/browser_bug597218.js.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

The leak logging may be confused by the fact that the entire session is very short-lived - it's kind of expected that you'd "leak [...] until shutdown" if you're shutting down very quickly after opening/closing windows.

Comment 3

[Luke Wagner [:luke]]

So there is some sort of race condition here?  How will this data be useful to developers?

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Assuming my theory about why this is occurring is correct, the data is still useful for runs of the entire test suite, since those runs take a long time (you're not expected to leak things in a 20 minute test run, whereas leaking things in a 2 second session might be reasonable). Maybe the window/docshell leak log analysis could take the session duration into account.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I looked into this because I was interested in how this leak tracking works. Here's what seems to be happening in the awesomebar test.

When the test starts (i.e., when it prints the TEST-START line), there's already a browser window open with a tab set to about:blank. As the test runs, it opens and closes a bunch of tabs. It finishes the same as it started, with a single window with an about:blank tab. However, this is a different about:blank tab than what we started with. The original one got closed and a new one was opened near the end of the test.

The leak checker code isn't smart enough to deal with this. It assumes that any windows created during the test should be GCed when the test is over. However, the new about:blank window lives past the end of the test, so it can't be collected.

This isn't really a huge deal for the entire test suite, since you never get more than a few false positives from this problem. However, it makes the leak checking pretty useless for single tests, which is annoying.

It seems like we ought to be able to fix this by printing out the currently open windows and document when all the tests end. Then those would get whitelisted.

Comment 6

[Luke Wagner [:luke]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #4)
Yes, turning this off for single tests would be a big improvement (even if we don't fix this test properly as billm suggested).  At the moment, I've basically just resolved, after constant false negatives, to completely ignore them.  That's a bad state for a reporting tool to be in.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Did http://hg.mozilla.org/mozilla-central/rev/c220dcb86e4e fix this?

Comment 8

[Luke Wagner [:luke]]

It improved comment 0 in that now it only reports 1 DocShell as leaked, no windows.  comment 1 still leaks a window and a docshell.

Comment 9

[Dão Gottwald [:dao]]

browser/base/content/test/browser_bug597218.js is bug 759711.

Comment 10

[Dão Gottwald [:dao]]

The docshell appears to be created after "Running step 12 - leave private browsing mode".

Comment 11

[Mark Banner (:standard8)]

I just ran this a couple of times on latest mozilla-central and there's no leaks.