[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/20245c2d97d0) { TEST-UNEXPECTED-FAIL | runtests-leaks | leaked 55744 bytes during test execution }

This is triggered by the following lines: { function setupDownloads() { stmt.params[prop] = data[prop]; function downloadExists(aID) stmt.params.id = aID; } and/or executing the statement.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20081210 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/89a175c70c25) After fixing bug 463513 (which fixed bug 462545) [soon on 1.9.1 branch], this is now the last (mochitest) leak ! blocking‑firefox3.1=?: Fixing it will allow us to reduce the BrowserChrome leak threshold to 0 :-)

Shawn - are there known leakiness things this test should be watching for with its sqlite calls? The statements are all reset() or finalized(). Unless there's something wrong with the code dolske added around executeSQL() leaking?

(In reply to comment #4) > Shawn - are there known leakiness things this test should be watching for with > its sqlite calls? The statements are all reset() or finalized(). Unless > there's something wrong with the code dolske added around executeSQL() leaking? There is no known leak in storage, but something weird is happening in both this bug, and bug 452899.

see bug 469062, if that's same issue i suppose if you change all params assignments to bindXXXParameter the leak will go away.

Bug 465952 "v1.0" patch did not fix this.

(In reply to comment #7) > Bug 465952 "v1.0" patch did not fix this. Bug 469972 !

while here, PlacesDBUtils needs the same changes to getters as PlacesDBFlush, that won't fix the leak though.

(In reply to comment #9) > while here, PlacesDBUtils needs the same changes to getters as PlacesDBFlush, > that won't fix the leak though. moved to bug 471547

If anyone gets a chance, a new leak log would be awesome (preferably with bug 471547 applied)

(In reply to comment #11) > If anyone gets a chance, a new leak log would be awesome (preferably with bug > 471547 applied) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090108 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/37ac7732142f) At first glance, it looks like bug 471547 checkin made no difference, as the tinderboxes confirm. NB: The attached 55k leak is when running the test alone, the 72k leak is when running the whole BrowserChrome suite, but they are otherwise the same one-and-only. Do you have problems running the test by yourself ?

(In reply to comment #12) > At first glance, it looks like bug 471547 checkin made no difference, On second glance, I confirm this; and running browser_sanitize-timespans.js alone doesn't leak (anymore) actually. Yet the "same" leak is still there ... stay tuned.

(In reply to comment #13) > stay tuned. I use python runtests.py --browser-chrome --test-path=browser/base/content/test --leak-threshold=0 --autorun --close-when-done with only browser_sanitize-timespans.js. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20090108 Minefield/3.1b2pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/20245c2d97d0) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/89a175c70c25) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/7d625a6b8a44) I confirm comment 1 and comment 3. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/62902ec9424a) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/e45938aee309) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/b98a20b1e91e) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/37ac7732142f) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/0ff733711384) But comment 8 was only partly right/wrong. (Comment 13 was right, though.) After bug 469972 fix, the behavior has changed: I can't reproduce the leak by running this test alone anymore. But if I run it with (for example) browser_alltabslistener [see leak bug 472677] or browser_page_style_menu and browser_pluginnotification [which don't leak by themselves] then this leak shows up again.

The patch in bug 473845 makes browser-chrome leaks go to zero for me.

Logs indicate that this is fixed with bug 473845 checked in.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090122 Minefield/3.2a1pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/aa69e508e312) V.Fixed

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv