465952 - browser_sanitize-timespans.js leaks

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P2)

Comment 1

[Serge Gautherie (:sgautherie)]

Attachment: Leak Log

[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
}

Comment 2

[Serge Gautherie (:sgautherie)]

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.

Comment 3

[Serge Gautherie (:sgautherie)]

[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 :-)

Comment 4

[Johnathan Nightingale [:johnath]]

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?

Comment 5

[Shawn Wilsher :sdwilsh]

(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.

Comment 6

[Marco Bonardo [:mak]]

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

Comment 7

[Serge Gautherie (:sgautherie)]

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

Comment 8

[Serge Gautherie (:sgautherie)]

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

Bug 469972 !

Comment 9

[Marco Bonardo [:mak]]

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

Comment 10

[Marco Bonardo [:mak]]

(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

Comment 11

[Shawn Wilsher :sdwilsh]

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

Comment 12

[Serge Gautherie (:sgautherie)]

(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 ?

Comment 13

[Serge Gautherie (:sgautherie)]

(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.

Comment 14

[Serge Gautherie (:sgautherie)]

(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.

Comment 15

[Shawn Wilsher :sdwilsh]

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

Comment 16

[Shawn Wilsher :sdwilsh]

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

Comment 17

[Serge Gautherie (:sgautherie)]

[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

Comment 18

[Gervase Markham [:gerv]]

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