473,385 Members | 1,942 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,385 software developers and data experts.

Memory Leaks, createElement, and Form Controls

(originally mis-posted on m.p.s.jscript...)

I've just closed all windows in Firefox and its using 244MB of memory.

I have no idea why. I had GMail open, a page from unicode, the CLJ FAQ.

I've noticed that createElement leaks. It's obvious with form controls
because the form keeps the control name as a property.

Example:

<!doctype html>
<body>
<form><input name="foo"/></form>

<script>
document.forms[0].foo;
document.forms[0].innerHTML = "";
document.write(document.forms[0].foo);
</script>
</body>

Will output:
[object HTMLInputElement]

(or similar implementation-dependent string).

If a node is added to the document, memory is allocated for that node.
When that node is removed, the memory usage goes back down, but not to
where it was before.

So FORM controls leak memory. This came up here:
http://groups.google.com/group/comp....ef6b0710?tvc=1

So what happens if I create, say 100 divs, then remove them?

Using Firefox 3.0.1
Well, I did that. I restarted Firefox. and noted the memory usage at "53mb".

I filled in "100" for the text input and clicked "periodicCreate()".

It reached 100 after a less than a minute. I checked the memory usage
again and it was 89.38mb.

I clicked "destroy" and waited a few minutes, watching the memory
increase and Firefox became unresponsive and CPU spiked to 100%.

"destroy" completed several minutes later, and I noted the memory usage
at 85.00mb.

A minute later, real memory remains at around 85mb. I reloaded the page.
85mb. I navigated to google.com. Still at 85mb.

Here is my test page:

<!DOCTYPE html>
<html lang="en">
<head>
<title>div Memory Leak</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<style type="text/css">
input { display: none; }
</style>
</head>
<body>
<h1>Adding DIV to DIV</h1>
<button onclick="create()">create()</button>
<button onclick="destroy()">destroy()</button>
<button onclick="periodicCreate()">periodicCreate()</button>
<input type="text" value="20" style="display:block" id='per'>
<pre id="mon">
Check memory consumption before starting.
</pre>
<pre id="mon2">
-
</pre>
<div id='cont'><!-- if the form element tag is changed to "div",
the leak does not occur --></div>
<script type='text/javascript'>
var mon = document.getElementById('mon'),
keyMon = document.getElementById('mon2').firstChild;
var p = document.getElementById('cont');
keys = [];
function create() {
var n = "n" + +new Date;
keys.push(n);
setTimeout(addInputs, 10);
}

function addInputs() {
var inp = document.createElement('div'),
c,
n = keys[keys.length-1];
for(var i = 0; i < 1000; i++) {
c = inp.cloneNode(false);
// add a title property,
// to increase memory.
c.title = "T" + i;
p.appendChild(c);
}
keyMon.data += (keys.length) + " name prefix: " + n + " please
wait.\r\n";
addInputs.done();
}
addInputs.done = function(){};

function periodicCreate() {
if(periodicCreate.i == +document.getElementById('per').value)
return;
create();
addInputs.done = function() {
periodicCreate.i++;
periodicCreate();
};
}
periodicCreate.i = 0;

function destroy() {
mon.innerHTML = "setting innerHTML = ''. Please wait...";
p.innerHTML = "";
mon.innerHTML = "done. Check memory consumption again.";
}
</script>

</body>
</html>
===========================================

So, Firefox leaks memory with createElement/appendChild.
Oct 5 '08 #1
11 4190
dhtml wrote:
I've just closed all windows in Firefox and its using 244MB of memory.
Wait till the FIREFOX.EXE process was terminated (as initiated by closing
all of its windows), then it will use 0M of memory. Besides, which memory
exactly?
[...]
I've noticed that createElement leaks. It's obvious with form controls
because the form keeps the control name as a property.
You have noticed nothing of the sort.
Example:

<!doctype html>

<body>
<form><input name="foo"/></form>

<script>
That is not even remotely Valid, and you are complaining?
document.forms[0].foo;
This does not do anything except reference resolution.
document.forms[0].innerHTML = "";
So you are trying to create an empty `form' element, which is not Valid.

<http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.3>
document.write(document.forms[0].foo);
</script>
</body>

Will output:
[object HTMLInputElement]
Works as designed. Good Thing.
(or similar implementation-dependent string).
So you are not even complaining only about Gecko-based UAs in the first
place? Because there is only one Gecko DOM implementation.
[...]
Here is my test page:

<!DOCTYPE html>
Not Valid again.
[...]
So, Firefox leaks memory with createElement/appendChild.
That is an incorrect assumption. Apparently you have neither understood
HTML, the DOM, or Windows memory management nor how garbage collection
works: an object that is no longer being referred to is eventually marked
for garbage collection that may or may not come later. It would be very
inefficient would garbage collection take place immediately after an object
would no longer being referred to.
PointedEars
Oct 5 '08 #2
On 05.10.2008 г. 14:33, /Thomas 'PointedEars' Lahn/:
dhtml wrote:
><!doctype html>

<body>
<form><input name="foo"/></form>

<script>

That is not even remotely Valid, and you are complaining?
>[...]
Here is my test page:

<!DOCTYPE html>

Not Valid again.
The later is well-formed XML (I guess SGML, too) DOCTYPE
declaration. The former appears to be valid HTML 5
<http://www.w3.org/html/wg/html5/#the-doctype>.

--
Stanimir
Oct 5 '08 #3
Stanimir Stamenkov wrote:
On 05.10.2008 г. 14:33, /Thomas 'PointedEars' Lahn/:
>dhtml wrote:
>><!doctype html>
[...]
<!DOCTYPE html>
Not Valid again.

The later is well-formed XML (I guess SGML, too) DOCTYPE
declaration.
Well-formed maybe, but not Valid.
The former appears to be valid HTML 5
<http://www.w3.org/html/wg/html5/#the-doctype>.
"HTML 5" is a Working Draft in its early stages, and of disputable authority.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Oct 5 '08 #4
Stanimir Stamenkov wrote:
On 05.10.2008 г. 14:33, /Thomas 'PointedEars' Lahn/:
>dhtml wrote:
>><!doctype html>
>
The later is well-formed XML (I guess SGML, too) DOCTYPE declaration.
The former appears to be valid HTML 5
<http://www.w3.org/html/wg/html5/#the-doctype>.
That doctype triggers standards mode. It won't pass the validator.

If desired, a full URI-doctype can be added to achieve the same effect.

Lets try to not focus on the extraneous noise and keep this focused and
on-topic.
Oct 5 '08 #5
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
>I've just closed all windows in Firefox and its using 244MB of memory.

Wait till the FIREFOX.EXE process was terminated (as initiated by closing
all of its windows), then it will use 0M of memory. Besides, which memory
exactly?
Closing all of the windows does not result in 0M of memory being used
(real memory).

>[...]
I've noticed that createElement leaks. It's obvious with form controls
because the form keeps the control name as a property.

You have noticed nothing of the sort.
The example was shortened for brevity. Validating the html does not
change the result.

>Example:

<!doctype html>

<body>
<form><input name="foo"/></form>

<script>

That is not even remotely Valid, and you are complaining?
>document.forms[0].foo;

This does not do anything except reference resolution.
>document.forms[0].innerHTML = "";

So you are trying to create an empty `form' element, which is not Valid.

<http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.3>
>document.write(document.forms[0].foo);
</script>
</body>

Will output:
[object HTMLInputElement]

Works as designed. Good Thing.
This is the result in Firefox. Opera has a different result. The first line:
document.forms[0].foo;

Does affect the result in Firefox.
So you are not even complaining only about Gecko-based UAs in the first
place? Because there is only one Gecko DOM implementation.
I'm not complaining, you are.

>So, Firefox leaks memory with createElement/appendChild.

That is an incorrect assumption. Apparently you have neither understood
HTML, the DOM, or Windows memory management nor how garbage collection
works: an object that is no longer being referred to is eventually marked
for garbage collection that may or may not come later. It would be very
inefficient would garbage collection take place immediately after an object
would no longer being referred to.
I'm not on Windows. Keeping the browser open for a long time after the
test complets doesn't change the result. I actually went away for 5
minutes and came back and memory usage was the same.
>
PointedEars
Oct 5 '08 #6
dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
I've just closed all windows in Firefox and its using 244MB of memory.
Wait till the FIREFOX.EXE process was terminated (as initiated by closing
all of its windows), then it will use 0M of memory. *Besides, which memory
exactly?

Closing all of the windows does not result in 0M of memory being used
(real memory).
(Did you notice that I was talking about the process's memory usage?)

Then you have either not waited long enough or you have much greater a
problem than supposed memory leaks from D::createElement. Probably an
extension blocking Firefox's termination (BTDT) as AFAIK Firefox does
not provide the Quick Start feature of Mozilla that keeps it running
in the background (CMIIW).
[...]
I've noticed that createElement leaks. It's obvious with form controls
because the form keeps the control name as a property.
You have noticed nothing of the sort.

The example was shortened for brevity. Validating the html does not
change the result.
True, but changing the markup might.
document.forms[0].foo;
This does not do anything except reference resolution.
document.forms[0].innerHTML = "";
So you are trying to create an empty `form' element, which is not Valid..

<http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-....>
document.write(document.forms[0].foo);
</script>
</body>

Will output:
[object HTMLInputElement]
Works as designed. *Good Thing.

This is the result in Firefox. Opera has a different result.
How different?
The first line:
document.forms[0].foo;

Does affect the result in Firefox.
In what way?
So you are not even complaining only about Gecko-based UAs in the first
place? *Because there is only one Gecko DOM implementation.

I'm not complaining, you are.
I am trying to analyse and rectify your incorrect assumptions instead.
So, Firefox leaks memory with createElement/appendChild.
That is an incorrect assumption. *Apparently you have neither understood
HTML, the DOM, or Windows memory management nor how garbage collection
works: an object that is no longer being referred to is eventually marked
for garbage collection that may or may not come later. *It would be very
inefficient would garbage collection take place immediately after an object
would no longer being referred to.

I'm not on Windows.
Right, I assumed from your posting in m.*.jscript before and other
clues in your posting that you were. Incidentally, it would have been
wise to name at least the exact version of Firefox you have been
testing with, including the window framework and operating system it
runs on, and the method of determining the process's memory usage
(that may be flawed).
Keeping the browser open for a long time after the
test complets doesn't change the result. I actually went away for 5
minutes and came back and memory usage was the same.
In case you did not quit the Firefox process: garbage collection is
not just a matter of time. However, as because of your inappropriate
assignment at least one element object was not marked for garbage
collection, and at least one other was created while "destructing" the
other, it would stand to reason that the memory usage did not
decrease, other factors aside.
PointedEars
Oct 6 '08 #7
On 5 Okt., 19:10, dhtml <dhtmlkitc...@gmail.comwrote:
Stanimir Stamenkov wrote:
On 05.10.2008 Ç. 14:33, /Thomas 'PointedEars' Lahn/:
dhtml wrote:
<!doctype html>
The later is well-formed XML (I guess SGML, too) DOCTYPE declaration. š
The former appears to be valid HTML 5
<http://www.w3.org/html/wg/html5/#the-doctype>.

That doctype triggers standards mode.
That DOCTYPE *declaration* may trigger "standards mode" (in whatever
browser you have tested with), but that does not mean much for
processing and the markup and handling it in DOM operations.
It won't pass the validator.

If desired, a full URI-doctype can be added to achieve the same effect.
The rest of your markup is not Valid as well, so changing the DOCTYPE
declaration is not going to make a considerable difference.
Lets try to not focus on the extraneous noise and keep this focused and
on-topic.
Noticing that the markup of a test case is not Valid is not extraneous
noise.
PointedEars
Oct 6 '08 #8
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
>Thomas 'PointedEars' Lahn wrote:
>>dhtml wrote:
I've just closed all windows in Firefox and its using 244MB of memory.
Wait till the FIREFOX.EXE process was terminated (as initiated by closing
all of its windows), then it will use 0M of memory. Besides, which memory
exactly?
Closing all of the windows does not result in 0M of memory being used
(real memory).

(Did you notice that I was talking about the process's memory usage?)

Then you have either not waited long enough or you have much greater a
problem than supposed memory leaks from D::createElement. Probably an
extension blocking Firefox's termination (BTDT) as AFAIK Firefox does
not provide the Quick Start feature of Mozilla that keeps it running
in the background (CMIIW).
Firefox should not terminate when the window is closed. Macs don't work
that way.

>This is the result in Firefox. Opera has a different result.
undefined.
>
How different?
>The first line:
document.forms[0].foo;

Does affect the result in Firefox.
If absent, the property will not be retrieved. The result of the second
getting of the |foo| property will be undefined. It seems that the
property will not be cached unless it is first gotten.

Firefox 3.0.1 on Mac.

>
In case you did not quit the Firefox process: garbage collection is
not just a matter of time. However, as because of your inappropriate
assignment at least one element object was not marked for garbage
collection, and at least one other was created while "destructing" the
other, it would stand to reason that the memory usage did not
decrease, other factors aside.
The initial element would not be collectible.

We've got a page that increases memory and that memory doesn't get
reclaimed. It seems like a memory leak. I can increase it to the point
where Firefox will cause a freeze. entering "400" will do that in Firefox.

Here's Example 1 with valid html (to the same effect) and a |bar| input
that is not referenced in script, plus the elements.foo property.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head><title></title></head>
<body>
<form action=""><input name="foo"><input name="bar"></form>
<pre>
<script type="text/javascript">
document.forms[0].foo;
document.forms[0].elements.foo;

// Clear out form's HTML.
document.forms[0].innerHTML = "";
document.write('foo: ' + document.forms[0].foo+'<br>');
document.write('bar: '+document.forms[0].bar+'<br>');
document.write('elements.foo: '+document.forms[0].elements.foo);
</script>
</pre>
</body>
</html>

Result:
foo: [object HTMLInputElement]
bar: undefined
elements.foo: undefined
Op9.5
foo: undefined
bar: undefined
elements.foo: undefined

After the innerHTML = "", there should be no more |foo| element in the
DOM. It is not gettable through elements collection, but can be gotten
directly off the form.

I disagree that this behavior is a Good Thing.

Garrett
>

PointedEars
Oct 6 '08 #9
Thomas 'PointedEars' Lahn wrote:
On 5 Okt., 19:10, dhtml <dhtmlkitc...@gmail.comwrote:
>Stanimir Stamenkov wrote:
>>On 05.10.2008 Ç. 14:33, /Thomas 'PointedEars' Lahn/:
dhtml wrote:
<!doctype html>
The later is well-formed XML (I guess SGML, too) DOCTYPE declaration.
The former appears to be valid HTML 5
<http://www.w3.org/html/wg/html5/#the-doctype>.
That doctype triggers standards mode.
>Lets try to not focus on the extraneous noise and keep this focused and
on-topic.

Noticing that the markup of a test case is not Valid is not extraneous
noise.
No, but stating that I don't understand HTML and so the test is invalid is.

I'm basing a "leak" as memory that does not get freed after a reasonable
amount of time (three minutes).

And now for safari 3.

Lauched, with blank window.
Real Memory Virtual Memory
14.64 MB 172.48 MB

Navigate some google searches, the FAQ page, and then open the test page:
Real Memory Virtual Memory
22.44 MB 190.75 MB

periodicCreate()
400

Result:
Real Memory Virtual Memory
167.38 MB 458.46 MB

destroy()

Result:
Real Memory Virtual Memory
167.38 MB 458.46 MB

Navigate away.
Wait a few minutes.
Real Memory Virtual Memory
99.23 MB 557.16 MB

Minimize Safari.
Wait a few minutes.
Real Memory Virtual Memory
99.23 MB 557.16 MB

Un-minimize Safari, close (only) window, clear cache.
Wait a few minutes.
Real Memory Virtual Memory
91.09 MB 549.89 MB
I observed an increase in memory in Safari 3, and an eventual decrease,
but not to the previous amount of memory.

Garrett
>

PointedEars
Oct 6 '08 #10
On Oct 5, 12:00*am, dhtml <dhtmlkitc...@gmail.comwrote:
Using Firefox 3.0.1
Well, I did that. I restarted Firefox. and noted the memory usage at "53mb".

I filled in "100" for the text input and clicked "periodicCreate()".

It reached 100 after a less than a minute. I checked the memory usage
again and it was 89.38mb.

I clicked "destroy" and waited a few minutes, watching the memory
increase and Firefox became unresponsive and CPU spiked to 100%.

"destroy" completed several minutes later, and I noted the memory usage
at 85.00mb.

A minute later, real memory remains at around 85mb. I reloaded the page.
85mb. I navigated to google.com. Still at 85mb.
<snip>
So, Firefox leaks memory with createElement/appendChild.
No, it doesn't. There are, of course, various patterns that will
leak, but this isn't one of them.

What you're noticing is a side-effect of Firefox's memory management,
and this is working as designed. Firefox handles its own memory
allocation, and once it grabs memory from the operating system it
won't free it back to the OS. So if the browser needs more memroy, it
takes it, uses it, and once it no longer needs it anymore (e.g. you
delete your divs, close a tab, etc), Firefox keeps that memory just in
case it needs it later.

The real test for this would be to load your div test, notice the
memory size increase. Then, close your tab, open it up again and run
your div test again. If your Firefox.exe memory size doesn't increase
by 36M again, then you don't have a leak.

If, however, it goes from 53M to 89M, then on the second test attempt
it goes to 125M, then yes you have a legitimate leak.
Oct 13 '08 #11
Nacho wrote:
On Oct 5, 12:00 am, dhtml <dhtmlkitc...@gmail.comwrote:
>
What you're noticing is a side-effect of Firefox's memory management,
and this is working as designed. Firefox handles its own memory
allocation, and once it grabs memory from the operating system it
won't free it back to the OS. So if the browser needs more memroy, it
takes it, uses it, and once it no longer needs it anymore (e.g. you
delete your divs, close a tab, etc), Firefox keeps that memory just in
case it needs it later.

The real test for this would be to load your div test, notice the
memory size increase. Then, close your tab, open it up again and run
your div test again. If your Firefox.exe memory size doesn't increase
by 36M again, then you don't have a leak.
(I am on a mac, BTW)
If, however, it goes from 53M to 89M, then on the second test attempt
it goes to 125M, then yes you have a legitimate leak.
Why does Firefox take memory when the page is not closed? After destroy,
there should a references to only one div.

Garrett

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
Oct 17 '08 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Mark D. Anderson | last post by:
About a month ago Richard Cornford did an interesting analysis of a memory leak in jscript (internet explorer) when there are "circular" references between DOM objects and (real) jscript objects:...
4
by: Morten Aune Lyrstad | last post by:
Ok, now I'm officially confused. I have a large project going, which uses a win32 ui library I am developing myself. And I'm getting weird memory leaks. I don't know if I can explain what is going...
12
by: Andla Rand | last post by:
Hi, I almost feel like giving up on developing on dotnet. I have done several threaded programs with the goal to parse webpages and I have tried WebClient and then WinSock. Both programs has...
3
by: Bhargavan | last post by:
Hi group, I have created a User control and whenever I use that usercontrol in a form, there is a memory leak. When I open and close the form, the form along with my user control is not disposed....
23
by: James | last post by:
The following code will create memory leaks!!! using System; using System.Diagnostics; using System.Data; using System.Data.SqlClient; namespace MemoryLeak
3
by: wonderu | last post by:
Hi! I have the AJAX-script. It eats memory about 4Kb per one callback. Script reflects messages from server application in real-time. I form messages, and put them into the iframe. If mesages more...
2
by: Robert | last post by:
Hello javascript group readers, I have a question regarding how to prevent memory leaks in Internet Explorer when using closures. I already knew about the circular reference problem, and until...
6
by: Andrew Poulos | last post by:
If I code something like the following it results in a memory leak in IE (as Leak 0.5 tells me): var frm = document.createElement("FORM"); document.body.appendChild(frm); fDeleteForm =...
8
by: BillE | last post by:
I have an existing asp.net 2.0 webforms app using master/content pages, and it works fine. I added some Ajax elements, including some UpdatePanels and modal PopUp panels which contain asp.net...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.