Creating a large dynamic table in an iframe leaks extra ordinary amounts of memory




14 years ago
13 years ago


(Reporter: bora123, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)



(1 attachment)



14 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 

Creating a large dynamic creately table into an iframe leaks till the end of WC 
(I dont know where that goes to, but it sounds pretty severe). I created 300 
rows with 4 columns in an iframe and Mozilla leaked 20Megs of memory. I still 
use 1.3.1 because it is much more sane DOMwise. From 1.4.0, the leak goes 
bananas to aroung(d) 40Megs of memory. It is a severe fact that You need more 
capable plugs. DOM has been getting worse since 1.3.1, dont know what is up 
that? By the way I am too lazy to report another bug for it but the events got 
very slow right from 1.4.0. A security check for each event handling must be in 

Reproducible: Always

Steps to Reproduce:

Actual Results:  
Leak goes uber WC.

Expected Results:  
It should use at least a reasonable amount of memory liek 4megs from IE.
No testcase, no steps to reproduce, no indication of why you think this is a
memory leak -- marking invalid.

Please feel free to reopen after providing some of the above information so that
this bug could actually be addressed.
Last Resolved: 14 years ago
Resolution: --- → INVALID

Comment 2

14 years ago
Nah, no testcases will be provided. It may stay invalid. Where is the new DOM 
redesign you guys have been talking about? All you have patched pipes and 
a ,still, oil burning diesel engine. The rpm of the engine is going down in 
every release. I admit it you guys are seriosly understaffed. But hey keep up 
the good work, at least the release number is moving.
> Nah, no testcases will be provided.

The problem with that is that if I can't reproduce the bug with code I create
(and I can't), then I have to read your mind to attempt to do anything about it.
 Unfortunately I am not a mind reader.

> Where is the new DOM redesign you guys have been talking about?

There has been no DOM redesign being talked about that I'm aware of...

Thank you for the insults and the waste of everyone's time.

Comment 4

14 years ago
No offense but I was not insulting anybody. I have numeruous times indicated 
before that you guys are doing a tremendous job considering this is a voluntary 
effort. I thought there was a Gecko 2.0 in works, and in parallel there would 
have been a talk of a new DOM design. It is not an insult if I call it a 
patched pipe, it is the hard working truth. Anyhow, I am sorry if I have 
insulted you in anyway. So, is there a design problem in Mozilla DOM that makes 
things working not very well?

What is an insult, sir, is telling us that we have a problem, refusing to help 
in any way in finding what the problem is, and then saying that the code is of 
poor quality. Criticizing code without showing any evidence that the criticism 
is well founded is an insult.

I am not aware of anyone else finding the bug you are referring to, so as far as 
everyone else is concerned, it is good, working code.

Comment 6

14 years ago
OK, very good then.

Comment 7

14 years ago
Created attachment 137202 [details]
Why this simple dynamic table takes 25 Megs of Memory

Why this simple dynamic table takes 25 Megs of Memory


14 years ago
Resolution: INVALID → ---
Um, are we talking memory usage here, or memory leakage? If you load the page 5
times after eachother, does Mozilla's memory usage go up as much (or at all)
with every consecutive load?


14 years ago
Attachment #137202 - Attachment mime type: text/plain → text/html

Comment 9

14 years ago
John, it is a memory usage problem as well as memory leak. I will put couple of 
more test cases demonstrating the problem in detail when I have time this 
Reporter, how about those leak testcases?

Comment 11

14 years ago
Sorry , I am too busy. How about trying to find out why that much of memory 
usage is necessary? 

Note: By the way, If I have time I will post tons of DOM bugs which made us 
stop supporting mozilla all together. Everything was fine with mozilla 1.3.1 
using NT and win2K. When we used an XP last week, we stopped it all together. 
We spent tons of man power and money for a working mozilla 1.3.1 version of our 
platform(a very complex DOM application), but it just didnt work at all on XP. 
Mozilla is way unpredictable, and we dont have neither time or money to go 
through all the operating systems out there. But I will submit those bugs when 
I have time.

good luck.
I just did a quick calculation of the minimal amount of memory we could possibly
be using on that testcase (using the bloat stats stuff to get base sizes for
objects and then manually computing subclass sizes).

We are creating 3500 rows, 5 cells each, 11 char textnode in each cell.  That means:

3500 <tr> objects (at least 32 bytes each, if the 28 bytes for generic element
                   includes the vtable pointers)
17500 <td> objects (at least 36 bytes each, similar constraint)
17500 textnodes (28 bytes each, plus 11 bytes for the text)
3500 table row layout objects (at least 72 bytes each, given the 44 for an
17500 table cell layout objects (at least 76 bytes each)
17500 celldata objects (4 bytes each)
17500 block layout objects (at least 64 bytes each)
52500 line box objects (since each block has three lines; at least 48 bytes
52500 text layout objects (one bit of text per line; 64 bytes each)
38500 XPCWrappedNative objects (one per row, cell, textnode since each is
                                accessed via DOM; 52 bytes each)

Total for that: 12 megabytes or so.  That's about half of the total memory
increase I am seeing, but maybe I'm forgetting some other obvious places where
memory would be used that the bloat log would not show?  Is the XPCWrappedNative
size correct?  It'd need to be _way_ off for it to account for the extra 12
megs.  It's also possible that the extra memory is allocated off the presshell
arena as a temporary during reflow then released back to the allocator, which
can't release it to the OS.  So it looks like we're using way more ram than we
really are.  See bug 130157.  I;m not sure how heavily we use the arenas during

As for the rest, just telling us that something broke doesn't help us or you. 
:(  I've seen many sites that were very complicated and relied on various bugs
break when those bugs got fixed; the alternatives are either to not fix bugs or
for people to let us know when changes we make break something....
One thing I have to wonder is whether we can garbage-collect some of the
XPCWrappedNatives... or do we?
Almost forgot.  Also 38500 JSObjects, which are kept from going away by the
rooting on the document.  Looks like at least 20 bytes each, which is another
770k or so...
A JSObject is 8 bytes of GC-thing, 1 byte of GC-thing flag, minimum 20 net (24
gross) malloc'd slots storage, and some share in a JSScope and its entrained
memory.  The JSRuntime.propertyTree stuff aggressively shares JSScopeProperty
structs, so you shouldn't see much memory tied up there.  Spacetrace or just a
couple of trace-malloc dumps seem like the tools to use here.

That involves having a trace-malloc or spacetrace enabled build, no?  Or are
those on by default in debug builds? is still
valid, I think.  Spacetrace is a separate app (a loopback http server, yet), and
running it and mozilla on the same system requires a ton of memory to perform
well (we have a 1GB system at Mozilla Headquarters set aside for space-tracing
-- dbaron may know more).

But just --enable-trace-malloc and you can use the scriptable JS methods
implemented around 
With TraceMallocDumpAllocations called from JS, you could get a before vs. after
dump, then do some sorting and comm(1)-based set differencing.


Comment 19

14 years ago
>As for the rest, just telling us that something broke doesn't help us or you. 
>:(  I've seen many sites that were very complicated and relied on various bugs
>break when those bugs got fixed; the alternatives are either to not fix bugs or
>for people to let us know when changes we make break something....

I know Boris, you are absolutely right; but days are only 24 hours, and we have 
tons of stuff on our table. I will submit those when I have time, I promise. In 
any case, we will need mozilla again in a near future. For now, I have to stick 
with our own priorities. On the other hand, glad to see you guys hammering down 
the memory usage phenomenan.

Re comment 18: I also wrote a perl script,
mozilla/tools/trace-malloc/ to show the differences (in tree
form) between two allocation dumps.

Comment 21

13 years ago
Could this be the scroll buffer of the IFRAME? How is the scroll buffer of the
IFRAME is handled as oppose to the normal browser frame's scroll buffer when
dynamic elements are added to the content? It really eats up extra ordinary
amount of memory for just 3500 rows. I think it is not DOM related. It gotto be
with something else like scroll buffer(may be). 

note: I made assumptions, hadnt looked at the code. cc'ing Robert.
Flags: blocking-aviary1.1?
That makes no sense.

Anyway, the leak testcases promised never appeared.  Marking bug invalid. 
Please reopen when you attach the testcases.
Last Resolved: 14 years ago13 years ago
Resolution: --- → INVALID

Comment 23

13 years ago
Okey so dynamicaly creating 3500 rows using 25 Megs of Memory is a perfectly 
valid behavior then. Very well, no more comments.

Flags: blocking-aviary1.1?
You need to log in before you can comment on or make changes to this bug.