Closed Bug 465952 Opened 16 years ago Closed 16 years ago

browser_sanitize-timespans.js leaks

Categories

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

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: sgautherie, Assigned: sdwilsh)

References

()

Details

(Keywords: memory-leak)

Attachments

(1 file)

No description provided.
Flags: wanted-firefox3.1?
Attached file Leak Log (deleted) —
[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 }
Blocks: mlkTests
Depends on: 460548
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.
Component: Preferences → Places
QA Contact: preferences → places
[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 :-)
Flags: blocking-firefox3.1?
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.
Blocks: 452899
No longer blocks: 452899
Blocks: 452899
Flags: wanted-firefox3.1?
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Assignee: nobody → sdwilsh
see bug 469062, if that's same issue i suppose if you change all params assignments to bindXXXParameter the leak will go away.
Blocks: 460548
Depends on: 469972
No longer depends on: 460548
No longer blocks: 452899
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 !
No longer depends on: 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.
Depends on: 472677
No longer depends on: 472677
(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.
Depends on: 469972
Target Milestone: --- → Firefox 3.1
Priority: -- → P2
The patch in bug 473845 makes browser-chrome leaks go to zero for me.
Depends on: 473845
Logs indicate that this is fixed with bug 473845 checked in.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
[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
Status: RESOLVED → VERIFIED
Target Milestone: Firefox 3.1 → Firefox 3.2a1
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: