590257 - Weird Leak in mochitest

Status: NEW

(Testing :: Mochitest, defect)

Description

[David Dahl :ddahl]

If you apply the attachments on bug 568629, 

Change the test (toolkit/components/console/hudservice/tests/browser/browser_ConsoleStorageServiceTests.js) as per the comment:

    var evt = "_foo_";

      // ******************************************************************
      // NOTE: this *test* leaks if you store anything but a string.
      // The ConsoleAPI tests also test this service, using real objects in
      // a real world situation.
      // To test this issue, change the line above to:
      // var evt = {woot: 123, baz: 456};
      // ******************************************************************



build like:

make -C dom && make -C layout/build && make -C toolkit/components/console && make -C toolkit/library

and run this test:

TEST_PATH=toolkit/components/console/hudservice/tests/browser/browser_ConsoleStorageServiceTests.js make mochitest-browser-chrome

This will leak an entire browser object (i think).

an integer will also leak a little bit, but the string does not leak at all.

Comment 1

[David Dahl :ddahl]

I should also mention that the test: 

TEST_PATH=toolkit/components/console/hudservice/tests/browser/browser_ConsoleAPITests.js make mochitest-browser-chrome

calls the API of the service that leaks a (few hundred times) and there are NO leaks:)

Comment 2

[(not currently active) Ted Mielczarek]

Is there a reason you think this is the test harness and not the browser code?

Comment 3

[David Dahl :ddahl]

(In reply to comment #2)
> Is there a reason you think this is the test harness and not the browser code?

Actually, I have no idea at his point. It could be either. I entered the bug in testing just to get ideas. The other test which uses the service extensively does not leak. sdwilsh, mossop and dietrich all had ideas on how to fix the leak, but none of us could figure it out.

Comment 4

[David Dahl :ddahl]

mak: do you have any ideas? No hurry! Just asking:)

Comment 5

[Justin Wood (:Callek)]

ddahl could this be similar to the XBL leak bug SeaMonkey had hit, which was exposed when we made tabs the default for us.

Basically, SeaMonkey was passing an _object_ to the SessionStore _service_. The object actually had the |window| JSContext/scope attached to it, so as long as the object was alive we'd leak the entire browser.

and that happend even if the object we stored was just |var foo = {}| from inside the XBL.

I don't know quite as much as I'd like about _why_ this is... but Neil did the investigation. CC-ing him incase this sounds similar to him [and incase he has cycles to comment]

Comment 6

[[e-mail]]

This looks like the same issue. Our service was listening to an event on a window and storing a reference to a JS object created by that window. In our case it was important that we maintained a reference to the same JS object, but then again we were able to make the service create the JS object, and have the window use that instead. In your case you may need to make your service sanitise the object via JSON. (You would have to do that both ways, otherwise you could leak by adding additional properties to the returned object.)

Comment 7

[David Dahl :ddahl]

I know the service is not leaking as I moved the test to xpcshell and stored the original objects. No leaks.

Comment 8

[[e-mail]]

Well, even I'd be surprised if you could leak a browser in an xpcshell test...

Comment 9

[David Dahl :ddahl]

(In reply to comment #8)
> Well, even I'd be surprised if you could leak a browser in an xpcshell test...

No doubt, however, the leaks were not just a browser window. If you pass an integer into the service in the mochitest, you get another leak - not a browser window.