Yesterday I proposed a new way of tracking leak reports. It’s now up and running. Two old tracking bugs have been decommissioned: bug 632234 (which was already resolved) and bug 640452. Five new bugs have been created:
-
Bug 659855 – (mlk-fx4-beta) [meta] Leaks and quasi-leaks reported against Firefox 4 betas
-
Bug 659856 – (mlk-fx4) [meta] Leaks and quasi-leaks reported against Firefox 4
-
Bug 659857 – (mlk-fx5) [meta] Leaks and quasi-leaks reported against Firefox 5
-
Bug 659858 – (mlk-fx6) [meta] Leaks and quasi-leaks reported against Firefox 6
-
Bug 659860 – (mlk-fx7) [meta] Leaks and quasi-leaks reported against Firefox 7
Please CC yourself if you are interested. Apologies for any bugspam you received as a result of these changes. Hopefully this new tracking system will work well.
5 replies on “The new leak tracking bugs are live”
great job!
a metabug’s probably a good idea, but even just doing some trivial testing earlier today it’s clear that ff4 has a “core” leak, and as long as that continues to sit unresolved you could end up exhausting yourself on “specific” leaks that are actually just misinterpretations of the core leak.
simplest example would be “load 1 page; load x more pages in tabs; close those x tabs; compare mem use with original 1 page state”. that may well cause ADDITIONAL leaks, but since ff4 can trivially be shown to leak roughly 1MB/minute without EVER opening more than 1 tab, focusing on a test case like that one could leave you barking up the wrong tree for days, since even if you fix any additional leaks from that you’ll still have a much larger footprint than at the original state because of the “base” leak.
best of luck.
noyb: I don’t see anything like a 1MB/minute memory growth rate. I do see a much smaller growth rate, AFAICT it’s due to the url-classifier that Firefox uses to provide phishing protection. (See https://bugzilla.mozilla.org/show_bug.cgi?id=650649#c22 for a ton of details about this.) It’s not even clear this is a leak, because that phishing info is constantly being updated and Firefox checks the server every 30 minutes or so to see if there are any new entries. In other words, just because the browser looks like it’s idle doesn’t mean it’s really idle. Lots of people see the memory usage increasing over a short period of time when they aren’t doing anything and assume it’s a leak.
There’s a similar story on the “load 1 page; load x more pages in tabs; close those x tabs; compare mem use with original 1 page state” test. There’s quite a bit of stuff that can hang around legitimately after those tabs are closed, but everyone again assumes it’s a leak.
Now, I’m not saying there aren’t leaks, but many “obvious leaks” are not as clear-cut as they first appear. I’m trying to work through these complicating issues as best I can.
everything you say there is potentially valid, agreed. however, it seems very unlikely since the rate doesn’t match; and even if it was, it would still represent an absolutely monstrous regression over 3.6, which doesn’t exhibit this problem.
just in case you misunderstood, the “1 -> many -> 1” test wasn’t what i was citing: it was an example of a case that *isn’t* necessarily valid, for the reasons you mention. my point was that trying to chase down cases like that, while still ultimately beneficial, may be a bad place to focus when just a single tab can showcase a major leak; even though the multi-tab case is a more “typical user scenario” and one that users are more likely to hold up as an example of ff’s leak problems.
i’ve long since reverted to 3.6 (mostly *because* of 4’s leaks, though the ui stupidity didn’t help) but i can easily put 4 (and 5) in a vm and disable the phish db next time i’ve got a couple of hours free and see what happens.
to put it bluntly, filing bug reports on ff leaks has historically been a waste of time. now that someone’s actually willing to admit that it *does* have problems and is trying to address them, i don’t mind burning some of my own time to try and pin down a trivial test case.
one quick observation, though i have no idea if it’s genuinely related or relevant, is that ff4 also used significantly more cpu in the test case (~10% more) which hints at jit as at least partly to blame. it would also support your db theory, but at a leak rate of ~64mb in ~50 mins it’s actually more like 1.25mb/min than 1.0, which you felt was already much higher than the db was causing. anyway, hopefully we’ll see in the next couple of days.
okay, the short version is: 4 is garbage, but the good news is 5 is much better already, so your efforts are clearly paying off. nice work, and thanks for that.
the less-good news is that 5 is still significantly worse in terms of *footprint* than 3.6 (75+MB once the test starts vs 60MB) and still has quite a way to go: 5 is 100+MB after an hour, while 3.6 is still under 65.
adding noscript to the 5.0 install made quite a difference, suggesting that part of the “base” bloat is a “valid” side-effect of firefox’s lack of XS security controls; and that a decent chunk of the additional bloat over time (which could easily be interpreted as leakage – correctly so, mind you) is from jit and/or it failing to release XSS’d resources (consider an ad frame on a 2-minute refresh, for example).