Handle Leaks with Microsoft.XMLDO M

[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\M icrosoft\Window s\CurrentVersio n\Internet
Settings\ZoneMa p

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("P OST", "<URL>" //where <URL> is the url that is
responding with xml data
xmlhttp.onready statechange=fun ction()
{
if (xmlhttp.readyS tate==4)
{
responseXML = xmlhttp.respons eText;
xmlDoc = new ActiveXObject(" Microsoft.XMLDO M");
xmlDoc.loadXML( responseXML);

for (i=0; i<xmlDoc.docume ntElement.attri butes.length;
i++)
{
currentId =
xmlDoc.document Element.attribu tes[i].nodeName;

document.getEle mentById(curren tId).innerHTML =
null;
document.getEle mentById(curren tId).innerHTML =
xmlDoc.document Element.attribu tes[i].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(nu ll);
delete xmlhttp;
xmlhttp = null;

[Dr John Stockton]

JRS: In article <11************ **********@g44g 2000cwa.googleg roups.com>
, dated Mon, 28 Nov 2005 09:38:59, seen in news:comp.lang. javascript, VK
<sc**********@y ahoo.com> posted :

// IE doesn't operate with the real time but with
// system ticks - 60ms per tick
// so setTimeout(..., 0,10,25,59) all means 60

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.demo n.co.uk/js-dates.htm#Ress>
would be appreciated.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Randy Webb]

Dr John Stockton said the following on 11/29/2005 3:07 PM:

<snip>

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

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.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Kevin Darling]

ty*****@gmail.c om wrote:

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\M icrosoft\Window s\CurrentVersio n\Internet
Settings\ZoneMa p
Have you tried making -- xmlDoc = new
ActiveXObject(" Microsoft.XMLDO M"); -- 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.

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 "responseXM L" as an intermediary variable. Perhaps directly
use:

xmlDoc.loadXML( xmlhttp.respons eText)

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

Just some ideas,
Kev

[rf]

Dr John Stockton wrote:

JRS: In article <11************ **********@g44g 2000cwa.googleg roups.com>
, dated Mon, 28 Nov 2005 09:38:59, seen in news:comp.lang. javascript, VK
<sc**********@y ahoo.com> posted :

// IE doesn't operate with the real time but with
// system ticks - 60ms per tick
// so setTimeout(..., 0,10,25,59) all means 60

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,

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.

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.

--
Cheers, Richard.

[Richard Cornford]

rf wrote:
<snip>

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.

<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.

[VK]

Dr John Stockton wrote:

VK <sc**********@y ahoo.com> posted :
// IE doesn't operate with the real time but with
// system ticks - 60ms per tick
// so setTimeout(..., 0,10,25,59) all means 60

Misleadingly inaccurate.

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

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>

[Martin Nedbal]

I just posted this comment to
microsoft.publi c.windows.inete xplorer.ie6.bro wser 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\M icrosoft\Window s\CurrentVersio n\Internet
Settings\ZoneMa p

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+windowsupd ate,
IE version 6.0.2900.2180.x psp_sp2_gdr.050 301-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+windowsupd ate).

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

With regards,
Martin

[Dr John Stockton]

JRS: In article <pJ************ *************** ***@comcast.com >, dated
Tue, 29 Nov 2005 18:40:50 local, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.com> posted :

Dr John Stockton said the following on 11/29/2005 3:07 PM:

<snip>

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

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.

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

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[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 :(

[Dr John Stockton]

JRS: In article <dm************ *******@news.de mon.co.uk>, dated Wed, 30
Nov 2005 01:27:40 local, seen in news:comp.lang. javascript, Richard
Cornford <Ri*****@litote s.demon.co.uk> posted :

rf wrote:
<snip>

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.

<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.

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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.