Bug 654106 was just fixed by Henri Sivonen. The leak was somewhere, in the HTML5 parser; a small amount of memory would leak any time .innerHTML was set on an element. Thanks to Henri for fixing it, to Hughmann for filing a wonderfully precise and easy-to-reproduce bug report, and to Boris Zbarsky and Mike Hommey for helping with the diagnosis.
With that bug fixed, that leaves 34 unresolved bugs hanging off bug 640452, the tracking bug for memory leaks.
2 replies on “Another leak fixed”
What kinds of bugs is your metabug intended to track?
I know roughly what it means that there are 625 unresolved bugs with the “mlk” keyword, but I don’t know what it means that there are 34 unresolved bugs you have chosen to track with bug 640452.
Jesse: good question. One response is to say those 625 bugs are bugs where somebody decided to add the “mlk” keyword, and the 34 bugs are bugs where somebody decided to make them block the tracking bug.
I created bug 632234 to track leaks that could potentially block Firefox 4.0. That worked really well, so I created bug 640452 to track leaks that could potentially block Firefox 5.0. Except we don’t really have blockers any more, but it’s the same basic idea. When I created it we looked like we’d be doing a new release every 3 months; now that the cadence is faster it seems worthwhile to have this bug open for a few releases.
So the main difference between the two tracking methods is freshness. Newer leaks have been marked as blocking the tracking bug. I’ve been paying attention to them, as have some other people. “mlk” bugs seem to get very little attention per se. And leak reports tend to get stale — a lot of them are vague, and it’s hard to know if they’ve been fixed. So I think there’s value in someone paying attention to an interesting and recent subset of them.
Hopefully we’ll get some MemShrink meetings going soon, then these bugs will get weekly attention. Any other ideas you have for reducing leaks would be welcome.