559683 - [HTML5] Memory Leak when leaving 'tbpl open for extended periods

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Open a tab to the URL above, leave it running and note that at each update interval the memory seems to jump 15+20meg, eventually eating tons of memory.  Over a 4hr period today, approximately, the browser became un-responsive, and was 'ghosting' the machine (win7 x64), and when I looked at the TaskManager Minefield was consuming 1.5gig RAM. 

Today's nightly build, but I suspect its been there a few days maybe, but today's build is the first I've seen the browser 'ghosting' and going 'not responding'.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is a longstanding issue last I checked (and filed, last I checked).  No one's been able to figure out whether it's a tbpl bug (holding on to lots of data) or a browser bug or some of both....

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

Closing the tab does release the memory that was consumed.  Today at work, using the 3.6.3 stable release, I have seen no memory creep, so something has changed in Minefield over the past couple of days that is causing this problem. 

As an aside not related - MSNBC also is leaking and eating memory slowly, likely also a javascript issue.  Also see the creep in Chrome Beta, but not in 3.6.3 stable.

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

Still looking for the regression range but its slow going.  Just when I think I have it narrowed down and recheck the suspect builds, they seem to run without any issue.  I have however, come up with a strong suspect in that its seemingly HTML5 related.  Turning off the HTML5 pref, the system ran 10hrs without any problems, where the same build with it enabled Minefield consumed 1.5gig and was sitting 'non-reponsive', and had to be killed.  

Now testing a nightly from 4/14/10 before bug 559311 landed.  Results tomorrow.

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

After lengthy testing it appears that bug 559311 or another that landed in the regression range is responsible for the memory leak/creep. 

The build: 20100414050851 fab327eb791b is OK with no memory consumption tested with HTML5 'on' and running for 12 hrs. 

The build: 20100415051417 d9d7de04f75d only ran for an hour 15mins before the memory use had crept up to over 400meg, and the browser was starting to become unresponsive and I noted that 'aeropeek' was toggling on/off on its own when the browser became unresponsive.  Turning off HTML5 seems to settle down the memory leak/creep. 

I'm not a coder, but I'm wondering if the cache change in bug 559311 is somehow not being garbage collected or something and it just keeps growing consuming resources ?

Comment 5

[Jim Jeffery not reading bug-mail 1/2/11]

Forgot to include my tabs for testing: 
CNN
MSNBC
Tinderbox for Firefox
tbpl page for Firefox 
and 6-7 other tabs from forums.

The CNN, MSNBC, Tinderbox, & tbpl all 'refresh' at periods, and it seems to be the refresh that will drive up the memory creep/leak when the browser is left running for an extended period of time.  

The 4/14/2010 build, and builds prior do not exhibit the memory creep/leak.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Interesting.
Henri, is it possible that HTML5 parser doesn't release some objects after it has
parsed something?

Comment 7

[Henri Sivonen (:hsivonen)]

nsHtml5TreeOpExecutor::mOwnedElements doesn't get cleared until the tree op executor is deleted. The fix is be making nsHtml5Parser::Reset() clear it.

See also bug 515941.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

Memory leak has stopped with the backout of 559311 - 

Closing.

tested with build: 
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100419 Minefield/3.7a5pre ID:20100419092554

cset: http://hg.mozilla.org/mozilla-central/rev/95310a8ac765