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 <am************ *************** @40tude.net>, dated Thu,
1 Dec 2005 01:49:32 local, seen in news:comp.lang. javascript, rf
<[e-mail] > posted :

Dr John Stockton wrote:

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.

But I severely doubt any of them do.

Agreed.

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 -

No. The PC architecture _provides_ a low frequeny counter. It is up to the
operating system to program that counter to its desired settings.

Evidently you do not know all that much about the PC architecture, and
have not read the references that I provided.

It's not wise to reprogram the 18.2 Hz by altering the divider ratio;
but the 18.2*65536 Hz drives a three-channel counter, and at least one
channel can be used for other purposes, OS or end-user.
In any case the system clock is only a side effect of the timer tick
interrupt. There are far more important things also hanging off the timer
tick, such as scheduling time slices for each running thread.

Fiddle with the timer tick *at your own peril*. It is, though, very hard to
do this anyway. The hardware access is buried in the kernel.
We were referring to whether the browser writer *could* access a higher
frequency (not raise *that* one; they are supposed to be skilled
professionals ...

Access seems easy enough in earlier versions of Windows.

there's the RDTSC instruction,
and the performance counter.

You mean the high-resolution performance counter?

That is what I mean by performance counter - the one accessed by
QueryPerformanc eCounter, not RDTSC (therefore the above "and").
Which reports the
contents of the hardware time-stamp counter, which is accessed with the
RDTSC instruction?
But that (implemented AFAICS in the CPU) is not what I mean by
performance counter.
This is there to investigate performance, not to schedule time dependent
events.
But either *could* be read to provide better time resolution. I have
written a program, INT_TEST.PAS, with a resolution of (0.5 or 1.0)/1.19
us.

On my system, the performance counter is at 1.19 MHz and is 64-bit;
there is a Win32 API to access it ---

The QueryPerformanc eCounter function retrieves the current value of
the high-resolution performance counter, if one exists.

BOOL QueryPerformanc eCounter(

LARGE_INTEGER *lpliPerformanc eCount
// address of current counter value
);

I've used it, in Delphi, without resort to ASM. Look it up in
Win32.hlp, if you can (my copy evidently came with Delphi). See in
TZ-CHECK, via <URL:http://www.merlyn.demo n.co.uk/programs/00index.htm>

In any case if one _were_ able to cause the performance counter to schedule
anything then the thread that handled that anything would only be itself
sheduled *during its next time slice*. That is, at the next timer tick, or
later.
But not relevant. Reading time is not equivalent to scheduling.
Windows is *not* a real time operating system. The granularity of the
entire system is the timer tick interval. Add a few other running threads
and the odd non-timer interrupt and, as Richard Cornford pointed out, it
becomes worse.

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

Write a driver, or whatever the current OS needs, to handle its
interrupt and to update a counter. Let the application read the
counter. I've processed the interrupt myself, in DOS; what I can do in
DOS a systems programmer can do in newer systems.
Regardless, this is drifting a little bit away from Javascript, except to
say that you will never get a time resolution better than the timer tick
using any of the javascript date/time functions. Indeed it will usually be
less. For once VK is right. Well, almost right :-)

That depends what you mean by the timer tick. If you mean the DOS timer
@ 18.2 Hz, then clearly Javascript in WinXP/IE6 beats that, using 64 Hz.
If you mean the timer tick that javascript uses, the remark is
tautologous.
--
© 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.

[Dr John Stockton]

JRS: In article <11************ **********@f14g 2000cwb.googleg roups.com>
, dated Thu, 1 Dec 2005 04:19:02 local, seen in
news:comp.lang. javascript, VK <sc**********@y ahoo.com> posted :

Here is the code I had. But before to proceed let's us recall what are
we talking about: I say that setTimeout / setInterval is not going by
real milliseconds but by system ticks set by the browser. Thusly any
time arguments are internally equal until you cross the border from one
system tick to another one. Thusly say setTimeout(f), setTimeout(f,0) ,
setTimeout(f,1 0) or setTimeout(f,25 ) are internally equal - lesser some
fluctuations caused by the system from one run to another.

One of your problems is that you don't understand enough to see what is
wrong with what you write even when you are told what is wrong.

I used to think that you are an Indian; but I've changed my mind.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[rf]

Dr John Stockton wrote:

JRS: In article <am************ *************** @40tude.net>, dated Thu,
1 Dec 2005 01:49:32 local, seen in news:comp.lang. javascript, rf
<[e-mail] > posted :

Dr John Stockton wrote:
[timer resolution]

A browser writer *could* go further.
But I severely doubt any of them do.

Agreed.

Fine, that is all we need to be aware of.
Evidently you do not know all that much about the PC architecture, and
have not read the references that I provided.

To the contrary, I know a great deal about PC architecture, to way back
before when there *were* PCs, just chips laying round on a breadboard, and
yes, I have read a couple of the references and find them sadly lacking,
for instance talking about the "DOS" clock for &deity;'s sake :-)

This *is* 2005 :-) You do *not* get to access the hardware any more and I
doubt that anybody of sane mind would include some sort of device driver
(and yes, I have written a few of them in my time so I know what they can
do) with a browser simply to get better timer resolution for some flashing
eye candy.

I really thought we were discussing the real world, with real operating
systems and real browsers. Evidently not.

I really don't need to pursue what some hyporthetical browser writer may in
theory do or not do. I have enough problems solving my bugs in the *real*
world :-)

--
Cheers, Richard.

[Martin Nedbal]

Martin Nedbal wrote:

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

Repying again to my own post - I talked to Microsoft guys here in Czech
Republic and according to them this bug is confirmed and hotfix is
planned to arrive in Feb 2006.

[Jasen Betts]

On 2005-12-02, rf <[e-mail] > wrote:

Dr John Stockton wrote:

JRS: In article <am************ *************** @40tude.net>, dated Thu,
1 Dec 2005 01:49:32 local, seen in news:comp.lang. javascript, rf
<[e-mail] > posted :

Dr John Stockton wrote:
[timer resolution]
A browser writer *could* go further.

But I severely doubt any of them do.
Agreed.

Fine, that is all we need to be aware of.

Evidently you do not know all that much about the PC architecture, and
have not read the references that I provided.

To the contrary, I know a great deal about PC architecture, to way back
before when there *were* PCs, just chips laying round on a breadboard, and
yes, I have read a couple of the references and find them sadly lacking,
for instance talking about the "DOS" clock for &deity;'s sake :-)

The dos clock (timer chip registers) could be read with microsecond precision
with a few lines of C. these give precision better than 1 microsecond.
This *is* 2005 :-) You do *not* get to access the hardware any more and I
doubt that anybody of sane mind would include some sort of device driver
(and yes, I have written a few of them in my time so I know what they can
do) with a browser simply to get better timer resolution for some flashing
eye candy.
<script type="text/javascript">
var x;
for( x=0;x<1000;++x)
document.write( +(new Date())+" ");
</script>

or if you have a slow PC (like me) try

<SCRIPT TYPE="text/javascript">
var x,y=new Array(1000);

x=1000;
while(--x)
y[x]=+(new Date());

x=1000;
while(--x)
document.write( (+y[x])+' ');

</SCRIPT>

In Linux (mozilla 1.7) this gives what appears to be milisecond precision,
ie repeated resullts with the same value written before the result changes
to the next number (without skipping any).

eg.

1133665943413 1133665943413 1133665943413 1133665943414 1133665943414
1133665943414 1133665943414 1133665943414 1133665943414 1133665943414
1133665943414 1133665943414 1133665943414 1133665943414 1133665943415
1133665943415 1133665943415 1133665943415 1133665943415 1133665943415
1133665943415 1133665943415 1133665943415 1133665943415 1133665943415
1133665943416 1133665943416 1133665943416 1133665943416 1133665943416
1133665943416 1133665943416 1133665943416 1133665943416 1133665943416
1133665943416 1133665943417 1133665943417 1133665943417 1133665943417
I really don't need to pursue what some hyporthetical browser writer may in
theory do or not do. I have enough problems solving my bugs in the *real*
world :-)

so how does your browser perform with this clock test.

Bye.
Jasen

[Jasen Betts]

On 2005-12-04, Jasen Betts <ja***@free.net .nospam.nz> wrote:

On 2005-12-02, rf <[e-mail] > wrote:

Dr John Stockton wrote:

JRS: In article <am************ *************** @40tude.net>, dated Thu,
1 Dec 2005 01:49:32 local, seen in news:comp.lang. javascript, rf
<[e-mail] > posted :
Dr John Stockton wrote:
[timer resolution]

> A browser writer *could* go further.

But I severely doubt any of them do.

Agreed.

Fine, that is all we need to be aware of.

Evidently you do not know all that much about the PC architecture, and
have not read the references that I provided.

To the contrary, I know a great deal about PC architecture, to way back
before when there *were* PCs, just chips laying round on a breadboard, and
yes, I have read a couple of the references and find them sadly lacking,
for instance talking about the "DOS" clock for &deity;'s sake :-)

The dos clock (timer chip registers) could be read with microsecond precision
with a few lines of C. these give precision better than 1 microsecond.

This *is* 2005 :-) You do *not* get to access the hardware any more and I
doubt that anybody of sane mind would include some sort of device driver
(and yes, I have written a few of them in my time so I know what they can
do) with a browser simply to get better timer resolution for some flashing
eye candy.

<script type="text/javascript">
var x;
for( x=0;x<1000;++x)
document.write( +(new Date())+" ");
</script>

or if you have a slow PC (like me) try

<SCRIPT TYPE="text/javascript">
var x,y=new Array(1000);

x=1000;
while(--x)
y[x]=+(new Date());

x=1000;
while(--x)
document.write( (+y[x])+' ');

</SCRIPT>

In Linux (mozilla 1.7) this gives what appears to be milisecond precision,
ie repeated resullts with the same value written before the result changes
to the next number (without skipping any).

eg.

1133665943413 1133665943413 1133665943413 1133665943414 1133665943414
1133665943414 1133665943414 1133665943414 1133665943414 1133665943414
1133665943414 1133665943414 1133665943414 1133665943414 1133665943415
1133665943415 1133665943415 1133665943415 1133665943415 1133665943415
1133665943415 1133665943415 1133665943415 1133665943415 1133665943415
1133665943416 1133665943416 1133665943416 1133665943416 1133665943416
1133665943416 1133665943416 1133665943416 1133665943416 1133665943416
1133665943416 1133665943417 1133665943417 1133665943417 1133665943417

I really don't need to pursue what some hyporthetical browser writer may in
theory do or not do. I have enough problems solving my bugs in the *real*
world :-)

so how does your browser perform with this clock test.

however settimeout (etc) seems less reilable, I'm not sure what underlying
OS feature is used for this timekeeping.

here we have steps of one, two or more miliseconds in response to a 1
milisecond setTimeout.

1133667849259 1133667849260 1133667849262 1133667849263 1133667849264
1133667849265 1133667849266 1133667849268 1133667849269 1133667849270
1133667849272 1133667849482 1133667849484 1133667849486 1133667849487
1133667849488 1133667849489 1133667849491 1133667849492 1133667849493
1133667849494 1133667849495 1133667849501 1133667849509 1133667849517
1133667849529 1133667849545 1133667849561 1133667849581 1133667849601
1133667849617 1133667849633 1133667849649 1133667849665 1133667849681
1133667849697 1133667849713 1133667849725 1133667849737 1133667849749

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=ISO-8859-1">
<TITLE>Java Script Test</TITLE>
<SCRIPT TYPE="text/javascript">
var x,y=new Array(100);
x=100;

function foo()
{ y[x--]=+(new Date());
if(x) setTimeout(foo, 1);
else
{ var s='';
x=100;
while(--x)
s+=((+y[x])+' ');
document.write( s);
}
}

foo()

</SCRIPT>
</HEAD>
<BODY>
<p>please wait for 100 ticks</p>
<div id="out"> results </br></div>
</BODY>
</HTML>

Bye.
Jasen

--

Bye.
Jasen

[Dr John Stockton]

JRS: In article <1c************ *****@clunker.h omenet>, dated Sun, 4 Dec
2005 03:24:22 local, seen in news:comp.lang. javascript, Jasen Betts
<ja***@free.net .nospam.nz> posted :

In Linux (mozilla 1.7) this gives what appears to be milisecond precision,
ie repeated resullts with the same value written before the result changes
to the next number (without skipping any).

eg.

113366594341 3 1133665943413 1133665943413 1133665943414 1133665943414
113366594341 4 1133665943414 1133665943414 1133665943414 1133665943414

Could you try & report, with that system,
<URL:http://www.merlyn.demo n.co.uk/js-dates.htm#Ress> , please ? Repeat
a few times, and maybe increase the Loop Count.

Than I can safely make an entry like
??? Linux ? Moz1.7 1 1

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

[Dr John Stockton]

JRS: In article <1d************ *****@clunker.h omenet>, dated Sun, 4 Dec
2005 03:55:19 local, seen in news:comp.lang. javascript, Jasen Betts
<ja***@free.net .nospam.nz> posted :

however settimeout (etc) seems less reilable, I'm not sure what underlying
OS feature is used for this timekeeping.

here we have steps of one, two or more miliseconds in response to a 1
milisecond setTimeout.

113366784925 9 1133667849260 1133667849262 1133667849263 1133667849264
113366784926 5 1133667849266 1133667849268 1133667849269 1133667849270
113366784927 2 1133667849482 1133667849484 1133667849486 1133667849487

ISTM that there may be considerably more overhead in setting a timeout
and responding than in grabbing a date (in a form which the OS may very
well already be maintaining).

You could try setting a 10 or 11 millisecond timeout to see if the same
bias and scatter occurs.

I don't know whether
<URL:http://www.merlyn.demo n.co.uk/js-date0.htm#TaI> will show anything
of interest.

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

[Jasen Betts]

On 2005-12-04, Dr John Stockton <jr*@merlyn.dem on.co.uk> wrote:

JRS: In article <1c************ *****@clunker.h omenet>, dated Sun, 4 Dec
2005 03:24:22 local, seen in news:comp.lang. javascript, Jasen Betts
<ja***@free.ne t.nospam.nz> posted :

In Linux (mozilla 1.7) this gives what appears to be milisecond precision,
ie repeated resullts with the same value written before the result changes
to the next number (without skipping any).

eg.

11336659434 13 1133665943413 1133665943413 1133665943414 1133665943414
11336659434 14 1133665943414 1133665943414 1133665943414 1133665943414

Could you try & report, with that system,
<URL:http://www.merlyn.demo n.co.uk/js-dates.htm#Ress> , please ? Repeat
a few times, and maybe increase the Loop Count.

Than I can safely make an entry like
??? Linux ? Moz1.7 1 1

pc Linux 2.6.13.2 Mozilla 1.7.8 1 1

I get resolution 1.16xxx but I'm almost certain that's
because of other tasks running in the background
and the correct value should be 1.00 , it's just this slow PC...
Yesterday I got microsecond resolution from gettimeofday()
(an os call, in a C program so I expect mozilla uses the
same time source)

BTW.
that table appears to the right of the text rather than under it like
all the other tables.

Bye.
Jasen

[Dr John Stockton]

JRS: In article <39************ *****@clunker.h omenet>, dated Mon, 5 Dec
2005 09:10:17 local, seen in news:comp.lang. javascript, Jasen Betts
<ja***@free.net .nospam.nz> posted :

On 2005-12-04, Dr John Stockton <jr*@merlyn.dem on.co.uk> wrote:

Could you try & report, with that system,
<URL:http://www.merlyn.demo n.co.uk/js-dates.htm#Ress> , please ? Repeat
a few times, and maybe increase the Loop Count.

Than I can safely make an entry like
??? Linux ? Moz1.7 1 1

pc Linux 2.6.13.2 Mozilla 1.7.8 1 1

I get resolution 1.16xxx but I'm almost certain that's
because of other tasks running in the background
and the correct value should be 1.00 , it's just this slow PC...
Yesterday I got microsecond resolution from gettimeofday()
(an os call, in a C program so I expect mozilla uses the
same time source)

I don't see that the Numerical Resolution can be other than an integer,
unless the individual new Date().getTime( ) readings are non-integer -
which I thought was not allowed. The Updating Interval could be over-
estimated in a busy system.

Thanks.
BTW.
that table appears to the right of the text rather than under it like
all the other tables.

Yes. Though there's only one other Table on the page, near the end.

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