Handle Leaks with Microsoft.XMLDOM

T

tydbowl

I have a problem where the below code chunk causes handle leaks on some
machines. The leak APPEARS to be handles to the registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap

The below code runs on a timer running several times per second and
after about 15-30 minutes or so, it runs out of handles and crashes IE.

I found an article on msdn discussing how setting properties in this
way could cause memory leaks if the reference to the nodeValue in the
div isn't set to null before leaving the page (they suggest doing this
in an unload function though of course, that does not quite work here
since we aren't unloading... we're just constantly updating the data).

Instead, as you can see below, I've set the div's innerHTML to null
prior to resetting it.... to no avail. Any help would be much
appreciated.

--Mike

var currentId;
var responseXML;
var xmlDoc;

var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
xmlhttp.open("POST", "<URL>" //where <URL> is the url that is
responding with xml data
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4)
{
responseXML = xmlhttp.responseText;
xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.loadXML(responseXML);

for (i=0; i<xmlDoc.documentElement.attributes.length;
i++)
{
currentId =
xmlDoc.documentElement.attributes.nodeName;

document.getElementById(currentId).innerHTML =
null;
document.getElementById(currentId).innerHTML =
xmlDoc.documentElement.attributes.nodeValue; //Note:
Commenting out this line removes the handle leak.... but of course that
also prevents my data from updating.
}
delete xmlDoc;
xmlDoc = null;
responseXML = null;
}

xmlhttp.send(null);
delete xmlhttp;
xmlhttp = null;
 
V

VK

I have a problem where the below code chunk causes handle leaks on some
machines. The leak APPEARS to be handles to the registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap

The below code runs on a timer running several times per second and
after about 15-30 minutes or so, it runs out of handles and crashes IE.

I found an article on msdn discussing how setting properties in this
way could cause memory leaks if the reference to the nodeValue in the
div isn't set to null before leaving the page (they suggest doing this
in an unload function though of course, that does not quite work here
since we aren't unloading... we're just constantly updating the data).

Instead, as you can see below, I've set the div's innerHTML to null
prior to resetting it.... to no avail. Any help would be much
appreciated.
Click to expand...

1. If your form's content allows that, try to switch from POST method
to GET and use send("") or (next to try) send(/*nothing*/) instead of
send(null)

2. Try to make a global counter for pending requests and do not let it
go over some limit: increase on each new request, decrease on each
successful request.

I would bet on #2 as the real problem but don't kill if I'm wrong.
 
T

tydbowl

VK, thanks for the reply.

I tried all of these options and the leak still occurs.

Any other ideas anyone?
 
V

VK

OK: first of all let's us narrow the problem: where does the leak
occur: in IXMLHTTPRequest or in DOM methods.

Forget for a second about AJAX - you don't need it really in IE. There
is much more reliable and convenient download behavior (build-in since
5.0)

<html xmlns:IE>
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">

var counter = 0;

function onDownloadDone(content) {
counter++;
$('out').innerHTML = content;
document.forms[0].elements[0].value = counter;
// IE doesn't operate with the real time but with
// system ticks - 60ms per tick
// so setTimeout(...,0,10,25,59) all means 60
setTimeout('fun()');
}

function fun() {
var spice = '?' + (new Date()).getTime();
// You may guess that "data.xml" should be provided:
$('loader').
startDownload('data.xml'+spice, onDownloadDone);
}

function $(id) {
return document.getElementById(id) || null;
}
</script>

<style type="text/css">
body { background-color: #FFFFFF}
</style>

</head>

<body onload="fun()">

<IE:Download id="loader" style="behavior:url(#default#download)" />

<div id="out">&nbsp;</div>

<form>
Loops: <input type="text" name="cnt">
</form>

</body>
</html>


On my test Win98 SE / IE 6.0 it held 3,000 loops like no problem. I
just cannot reserve the computer for the entire day to see the
"work-on-denial" limit but it's definitely not 30-40 loops like in your
case. You have to improve your algorithm I guess.
 
T

tydbowl

Thanks VK, I'll test out that code and see how it goes on the test
machine.

Just some additional info: My original code does NOT have handle leaks
on most machines, but it does on a few. The system info for the
problematic machine is:

Windows XP SP2
IE version: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519

Thanks again for that sample. Unfortunately, the code needs to support
firefox, mozilla, and opera, so I'm not sure if the xmlns:IE and the
IE:Download tags will be supported... but I'll give it a shot and let
you know.

Thanks,
--Mike
 
V

VK

tydbowl said:
Thanks VK, I'll test out that code and see how it goes on the test
machine.

Just some additional info: My original code does NOT have handle leaks
on most machines, but it does on a few. The system info for the
problematic machine is:

Windows XP SP2
IE version: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519

Thanks again for that sample. Unfortunately, the code needs to support
firefox, mozilla, and opera, so I'm not sure if the xmlns:IE and the
IE:Download tags will be supported... but I'll give it a shot and let
you know.
Click to expand...

Behaviors are IE-exclusive, so it will not work for Firefox or Opera.

I gave this code to narrow the possible leak source: <download>
behavior doesn't leak for sure for IE 5.5 and higher. I just checked it
on Windows XP SP1 for 5,000 loops.

So you may want to run this sample exactly as it is on the machines of
question to see their work-on-denial limit. If it still crashes any
soon then the problem is:
1) either in the JScript / MSXML behavior difference
2) or in some DOM holes (for example innerHTML was known to be leaky -
but long time ago).

JScript has special versioning methods:
alert(ScriptEngineMajorVersion() + '.' + ScriptEngineMinorVersion())
will give you the actual JScript version running on the machine.

Compare it.

If the machine of the question has a lower version, update JScript
from:
<http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp>
 
T

tydbowl

The code sample provided does not leak. But then again,when I comment
out the line of code next to the "Note:" in my original sample, the
leaks also dissappear.

It appears the leaks only occur when I set the innerHTML to the value
of an XMLDOM node.

Also I checked the JScript version as you suggested. Both leaky and
non leaky machines print out "5.6" (.... Though I'm admittedly not
sure if the JScript version is the samething as the javascript
version... I don't know enough about the two terms to know if they are
really different under the covers).

I'm going to play with that sample and replace the "$('out').innerHTML
= content;" line with the XMLDOM code from the original sample and see
if the leak occurs. I presume it will.
 
V

VK

tydbowl said:
Though I'm admittedly not
sure if the JScript version is the samething as the javascript
version... I don't know enough about the two terms to know if they are
really different under the covers).
Click to expand...

Mozilla Foundation (and many others) is going by the conventional
versioning where JavaScript 1.0 is the first one in Netscape 2.x and
JavaScript 1.5 is the current one.

ECMA docs are based on the description of Netscape 4.? (don't remember
- 4.5 or something) They have something atop of 1.2 and something
missing from 1.3 (minus all Netscape stuff ECMA considered to be not
enough academical). So it's kind of 1.2+/- or 1.3-- :)

Microsoft mainly goes by Internet Explorer versions: so JScript 5.5 was
first shipped with IE 5.5.
*Approximately* JavaScript 1.5 corresponds to JScript 5.5 (keeping in
mind all browser-specific features) and this was the basic ground for
several last years.
I'm going to play with that sample and replace the "$('out').innerHTML
= content;" line with the XMLDOM code from the original sample and see
if the leak occurs. I presume it will.
Click to expand...

May I see what are you actually inserting into innerHTML?
You may put any foobar text content but keep all tags
 
T

Thomas 'PointedEars' Lahn

VK said:
Mozilla Foundation (and many others) is going by the conventional
versioning where JavaScript 1.0 is the first one in Netscape 2.x and
JavaScript 1.5 is the current one.
Click to expand...

What "conventional versioning" are you talking about? JavaScript is an
independent language implementation, of course its versioning is different
than other (ECMAScript) implementations.
ECMA docs are based on the description of Netscape 4.? (don't remember
- 4.5 or something) They have something atop of 1.2 and something
missing from 1.3 (minus all Netscape stuff ECMA considered to be not
enough academical). So it's kind of 1.2+/- or 1.3-- :)
Click to expand...

Nonsense. As the ECMAScript Specification and the JavaScript Guide(s)
state,

- ECMAScript 1 was based on JavaScript 1.1 (NN3) and JScript 1.0 (IE3).
- JavaScript 1.2 (NN 4.0-4.05) is not fully compatible with ECMAScript 1.
- JavaScript 1.3 (NN 4.06-4.8) is fully compatible with ECMAScript 1.
- JavaScript 1.4 (not implemented to my knowledge) is fully compatible
with ECMAScript 1.
- JavaScript 1.5 (Mozilla/5.0 browsers incl. NN6) is fully compatible
with ECMAScript 3.
- JavaScript 1.6 (Mozilla/5.0 rv:1.8b+ browsers incl. upcoming Firefox 1.5)
is probably fully compatible with ECMAScript 3 (CMIIW).

Unfortunately, there is no such compact description for JScript versions in
the MSDN Library. However, Microsoft explicitly states several features in
JScript (.NET) not to be "ECMAScript compliant" or "not provided by the
ECMAScript language":

<URL:http://msdn.microsoft.com/library/en-us/script56/html/js56jsoriVersionInformation.asp>
Microsoft mainly goes by Internet Explorer versions: so JScript 5.5 was
first shipped with IE 5.5.
Click to expand...

True, however unlike JavaScript versions, JScript versions are independent
of the browser version in a way that the Script Engine can be upgraded
independently. Hence JScript 5.5 is the minimum version that can be
expected on IE 5.5 _for Windows_ (there appears to be a difference in
script support between in IE versions for Windows and IE versions for Mac).
*Approximately* JavaScript 1.5 corresponds to JScript 5.5 (keeping in
mind all browser-specific features) and this was the basic ground for
several last years.
Click to expand...

That remains to be seen. I do not think you have the knowledge required to
assess that. Neither have I yet, however I think my feature support matrix
on <URL:http://www.pointedears.de/scripts/js-version-info> will allow me to
assess that once it is complete.


PointedEars
 
R

Richard Cornford

VK wrote:
ECMA docs are based on the description of Netscape 4.?
(don't remember - 4.5 or something) They have something
atop of 1.2 and something missing from 1.3 (minus all
Netscape stuff ECMA considered to be not enough academical).
So it's kind of 1.2+/- or 1.3-- :)
Click to expand...
<snip>

I realise that you consider the stories in your head as more true than
anything else, but do you really think that it does anyone any good at
all for you to be posting this pack of lies?

Richard.
 
D

Dr John Stockton

JRS: In article <[email protected]>
, dated Mon, 28 Nov 2005 09:38:59, seen in VK
// IE doesn't operate with the real time but with
// system ticks - 60ms per tick
// so setTimeout(...,0,10,25,59) all means 60
Click to expand...

Misleadingly inaccurate.

In Win98, IE4 uses ticks at about 54.9 ms intervals, and new Date() has
a resolution of 10 ms.

The interval and resolution depend on the OS/browser combination, I've
been told that IE on Mac OS X gives 1 ms for both.

AISB, read the newsgroup FAQ; see below.

More results for/from
<URL:http://www.merlyn.demon.co.uk/js-dates.htm#Ress>
would be appreciated.
 
K

Kevin Darling

I have a problem where the below code chunk causes handle leaks on some
machines. The leak APPEARS to be handles to the registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap
Click to expand...

Have you tried making -- xmlDoc = new
ActiveXObject("Microsoft.XMLDOM"); -- a static variable instead of
creating it each time?

Is there any security involved as far as accessing the server?
The below code runs on a timer running several times per second and
after about 15-30 minutes or so, it runs out of handles and crashes IE.
Click to expand...

Is it possible that the webserver is running out of connections?
That'll mess up xmlhttp sometimes.

Also, be aware that in some IE 6's, if you use onUnload you sometimes
have to also call abort() on xmlhttp to clear things up correctly. (I
know this isn't your case, though.)

Another suggestion is to not only make the xmlDoc a static, but avoid
using your "responseXML" as an intermediary variable. Perhaps directly
use:

xmlDoc.loadXML(xmlhttp.responseText)

And instead of creating a function each time for the
xmlhttp.onreadystatechange, just point to a static one.

Just some ideas,
Kev
 
R

rf

Dr said:
JRS: In article <[email protected]>
, dated Mon, 28 Nov 2005 09:38:59, seen in VK


Misleadingly inaccurate.

In Win98, IE4 uses ticks at about 54.9 ms intervals, and new Date() has
a resolution of 10 ms.

The interval and resolution depend on the OS/browser combination,
Click to expand...

Not inaccurate, merely misleading.

The timer tick interval depends on the OS and has nothing to do with the
browser.

The win9x family of operating systems use an interval of 54 odd ms. The NT
family differ. I cannot recall what NT3.x and NT4 use but NT5 (2000) and
NT5.1 (XP) use 15 odd ms although some have been reported to use 10 odd ms.
Windows server 2003 uses 100ms or 200ms, can't remember which.

The resolution of any function that access the system clock (which is
updated at timer tick) would be exactly the same as the timer tick. There
is, after all, only one clock.

There are low level API functions which will change the timer tick interval
as a side effect but these functions would rarely be used by a normal
application like a browser as they are not aimed at time but rather
performance in near real time multithreaded applications.
I've
been told that IE on Mac OS X gives 1 ms for both.
Click to expand...

The documentation that details the above low level functions (microsoft of
course) warns that causing the timer tick to drop below 2ms can have
disasterous results on system performance. Perhaps Mac OS X uses a
different architecture to maintain the system clock.
 
R

Richard Cornford

rf wrote:
The resolution of any function that access the system clock
(which is updated at timer tick) would be exactly the same
as the timer tick. There is, after all, only one clock.
Click to expand...
<snip>

I am not sure that you can go that far. The resolution of a function
that accesses the system clock can be no better than the OS tick, but it
could be worse.

Richard.
 
V

VK

Dr said:
Misleadingly inaccurate.

In Win98, IE4 uses ticks at about 54.9 ms intervals, and new Date() has
a resolution of 10 ms.
Click to expand...

As I like to say: "Do not mix a God's gift with a omlet" (means "to do
not think the same on two totally diffrent things").

When you run a separate application it can be only as accurate as the
system tick of the particular OS (50ms? on Win98 -... - 10ms? on
Linux).

If you want a better accuracy (say bor benchmarking) you have to
program a low-level hardware access to the system clock.

When you run a JavaScript program it can be only as accurate as the
system tick set for the host application which is Internet Explorer in
our case.

Nevertheless the system usually keeps you out of this timing "misery",
so say in Java you even can use nanoseconds and still get some
true-looking results. It achieved by calculating the average interval
by formula ms = (system tick)*(n of ticks) + (lower byte spice)

This explain some fantastic system ticks like 54.9 ms ;-) I assure you
that no system runs on such periods.

More useful reading (besides OS specs) :
<http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/truespeed.asp>
 
M

Martin Nedbal

I just posted this comment to
microsoft.public.windows.inetexplorer.ie6.browser and it should go here
as well.
I have a problem where the below code chunk causes handle leaks on some
machines. The leak APPEARS to be handles to the registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap
Click to expand...

Hi,
I'm just fighting exactly the same problem, but I don't think that this
is only related to XMLHTTP. I have latest WindowsXP (SP2+windowsupdate,
IE version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519). My IE seems to open
new handles each time I :

.. set src on SCRIPT element (2 handles)
.. set src on IFRAME element (2 handles)
.. set src on IMG elment (2 handles)
.. set innerHTML propery to some text (=no new elements) on DIV (or any
other visual element) (2 handles)

IE starts with 12 handles (having about:blank as homepage), then it
takes randomly another 2 or 4 handles each time I load the age/press
F5. This appears even if the page loaded is a 403 for instance. It's
not related to user auth scheme (I found this problem in out
application which is using NTML but it's the same even for anonymous
access). It's not related to membership of the server in zones - it
does the same when I put the server into "trusted" and when it's not
there. I've created small test page which allows you to test the
actions I mentioned (http://linda.cooper.cz/awe/test/ie/).

When the number of opened handles reaches 64k IE partly stops working,
if you had a server in "trusted" zone it starts to recognize it as
"internet" etc.

I'm going to test that on clean WindowsXP and then after each
servicepack/IE update to find the one which caused this problem but
this will take some time. Another clue might be that this behavior
can't be reproduced on Windows 2000 (SP4+windowsupdate).

Feel free to contact me if you need to clarify things/get additional
information.

With regards,
Martin
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated
Tue, 29 Nov 2005 18:40:50 local, seen in
Randy Webb said:
Dr John Stockton said the following on 11/29/2005 3:07 PM:



IE6 on Win XP SP2 gives me 15.6/15.7 for Update Interval. It alternates
between the two for the most part. Numerical Resolution of 1.
Click to expand...

Thank you; entered. If you increase Loop Count to 100 you should get
15.62/15.63; to 1000, 15.625, if not interrupted.
 
M

Martin Nedbal

t's strange to reply to one's own post, but - the problem is caused by
hotfix 896688, the only trouble is that it fixes quite a holes in
security :(
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated Wed, 30
Nov 2005 01:27:40 local, seen in Richard
Cornford said:
rf wrote:

<snip>

I am not sure that you can go that far. The resolution of a function
that accesses the system clock can be no better than the OS tick, but it
could be worse.
Click to expand...

A browser writer *could* go further.

In the PC architecture, the 54.9 ms clock is obtained by division by
65536, and the signal that drives that can be divided by other numbers.
Signals of much higher frequency can be read in Win98/PII and higher -
there's the RDTSC instruction, and the performance counter.

Additionally, there's the PC RTC, driven by a 32 kHz crystal, which
could be used.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

In Firefox null gets assigned before XHR returns. Works in IE. 9
In Firefox (2.0.0.18) .readyState hung at 3 while .responseText hasthe data but .responseXML is nul. 18
Passing querystring variable to function 3
need help with generic ajax get function 6
Script working in Firefox but not IE7 5
Help with JavaScript 4
? Trouble with: passing dragElement(e.target.id); 8
JS ajax request 15

Members online

No members online now.
Total: 25 (members: 0, guests: 25)
Robots: 424

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,053
Latest member
BrodieSola

Latest Threads

Top