166298 - dhtml memory leak

Status: RESOLVED DUPLICATE of bug 117316

(Core :: DOM: CSS Object Model, defect)

Description

[David Finch]

On a test page I wrote that creates and destroys hundred divs each frame to
display a moving line, I observed a fairly rapid memory leak of about 1/2 mb/s
on my 500mhz celeron running win98se. I'm using Mozilla 1.0 on this computer.

Comment 1

[David Finch]

Attachment: test page that I observed the leak on.

When left running for several minutes, I lost roughly 300 mb of ram, about 80mb
physical and the rest swap.

Comment 2

[Markus Hübner]

confirming - using trunk build 2002090108 on win-xp pro.
might this be related to bug 117316 ?

put the testcase online at http://www.world-direct.com/mozilla/dhtml/test.html 
for easier testing.

Comment 3

[Johnny Stenback (:jst)]

We get back the memory that the page consumes when you leave the page, is the
page holding on to some of the data it works with?

Comment 4

[David Finch]

It was still holding on to most of the memory after I tried visiting another 
page in Mozilla 1.1 on win2k.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  In my testing, it looks like you have to let it run for a bit.  Then the
memory usage will start growing quickly.  Leaving the page stops the growth but
does not release the memory.  Going back to the page does not grow the memory
for a long time (as long as you ran it the first time).

It feels like there's some datastructure that keeps growing with time on this
page... when we leave the page we release it all, but malloc() can't give the
memory back to the OS.  But the next time we have all that space to grow into....

dbaron, I have a sneaking suspicion that Matic's comment 2 is right and the data
structure in question is the ruletree... we're creating lots and lots of style
attributes (and corresponding inline style rules).  And the ruletree is holding
on to them all...

Comment 6

[Harshal Pradhan]

With 1.2alpha, I still see memory growth, but get it all back on closing the tab
or moving away to another page. 

At a guess, this originally might have been bug 158674 combined with 117316. Now
that that one is fixed, this might just be a dup of 117316.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Using trace-malloc (with HAVE_BOUTELL_GD defined in the Makefile.in, since
there's no configure.in test) on a build with DEBUG_TRACEMALLOC_FRAMEARENA
defined in nsPresShell.cpp shows that most of the allocations are of CSS rule
structures (owned by rule nodes) and of rule nodes.

*** This bug has been marked as a duplicate of 117316 ***

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That should have said "and spacetrace" (which was the reason for my configure.in
complaint).