558958 - [10.6] Cycling page test causes large memory leak

Status: RESOLVED INCOMPLETE

(Core :: General, defect, P3)

Description

[John Daggett (:jtd)]

While doing some testing for bug 449292, I came across what appears to
be a leak that occurs only on 10.6.  The tests cycle through a set of
pages in an iframe.

In the chart below, ignore the values marked "Harfbuzz", the values
marked "Coretext" reflect current trunk code.  Note how on 10.5 a
relative equilibrium state is reached but on 10.6 memory usage grows
continually:

  https://spreadsheets.google.com/ccc?key=0ArCKGq7OfNmMdGJZamY2MTlCTXRQUEo4Yk5qZE80WEE&hl=en

The memory usage value is the resident set size of the Firefox
process, it's the memory usage of the entire app and not just a
font-related component (ps -o etime,rss).

Testcase described in bug 449292, comment 41.  My tests were done with
Harfbuzz installed but I see the same behavior with a trunk build.

Comment 1

[Josh Aas]

Thanks for the info John.

Throwing an idea out there... If this is specific to Mac OS X we might want to check how many objects are ending up in our root autorelease pool (nsAppShell's mMainPool). Perhaps debug builds should output the count when the browser shuts down.

Comment 2

[Jonathan Kew [:jfkthame]]

FTR, this is not a new issue on trunk - I see similar memory growth running 3.6.3 on 10.6.2.

Comment 3

[Jonathan Kew [:jfkthame]]

Also seems to happen with Firefox 3.5.8 .... it's reached well past 400MB after 15 minutes.

Comment 4

[Josh Aas]

I'm not sure it is responsible for this bug, at least not entirely, but my autorelease pool theory did lead me to discover significant leaks including font objects. See bug 559047.

Comment 5

[Damon Sicore (:damons)]

blocking 1.9.3 final+

Comment 6

[(no longer active)]

John, are you going to work on this?  If so, could you please assign it to yourself?  I was browsing through the list of unassigned blockers, and found this, but it doesn't seem like something that I could work on effectively...

Comment 7

[Joe Drew (not getting mail)]

Can someone re-run these numbers?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 10

[Hani Yacoub, Desktop QA]

Closing this as resolved: incomplete due the long time this bug was logged, the functionality most likely changed since then.
Please feel free to reopen this bug if you think otherwise.