Memory Leak IE Javascript attribute add onblur

[Joshua]

I posted this originally in the csharp group, but I think that may be
the wrong group. This seems more appropriate:

I'm running into an issue with a memory leak in an Asp.Net web page.

In the code behind (.cs) I'm adding onchange, onblur and onfocus
events to a bunch of objects that reside on my page (textboxes and
dropdownlist).

After using Drip i've found that these are leaving open DOM objects.

Does anybody know how to kill these when I exit the page?

Thank you very much.

some responses:

Joshua,

For most any browser that has a javascript engine, there is a garbage
collector which will take care of this for you.

Which browser are you working with? If you exit the page, then
eventually, the gc for the javascript engine should eventually clean things
up.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)
The javascript engine on the client side in IE

That should not be a problem. Javascript is managed, it means that you don't
have to release the memory.

Are you sure that is the problem?

And my response to them:

I'm using Drip to identify these because the javascript garbage
collector is not taking care of it. After using the page for a while,
entering and exiting, the memory grows so much that they have to close
the browser and reopen it - it grows and does not go down after
exiting the page or even the site. I'm tacking the memory using the
task manager, process tab watching iexplore.exe. I'm using IE 7 (or
6). However the Drip program I saw was suggested by others to
identify open DOM calls (in reference to leaked memory). I'm just not
sure how to kill the open DOM calls. Is there some javascript call
that I can use on the unload to kill these?

The page has some ajax toolkit items (calendar and cascading dropdown)
and makes some web service calls as well.

 

[Henry]

I posted this originally in the csharp group, but I think that
may be the wrong group. This seems more appropriate:

I'm running into an issue with a memory leak in an Asp.Net
web page.

In the code behind (.cs) I'm adding onchange, onblur and
onfocus events to a bunch of objects that reside on my
page (textboxes and dropdownlist).

But what your "code behind" is doing is generating HTML and/or client-
side javascript, which is actually doing the work of adding event
handling functions to HTML elements (or causing that work to be done,
but still on the client). You (or someone who understands it) need to
be looking at the HTML and/or javascript output from your servers and
sent to the browser to be interpreted/rendered/executed there.

After using Drip i've found that these are leaving open DOM
objects.

Does anybody know how to kill these when I exit the page?

Yes, but not in any way specific to your code. IE's famous memory leak
issue is caused by the existence of circular references between
javascript objects and COM object (which means DOM Nodes and ActiveX
objects). You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).

Thank you very much.

some responses:

<snip>

Contrary to what Microsoft's documentation says, the memory leaks in
IE caused by circular references are not freed until IE is closed down.

 

[Joshua]

But what your "code behind" is doing is generating HTML and/or client-
side javascript, which is actually doing the work of adding event
handling functions to HTML elements (or causing that work to be done,
but still on the client). You (or someone who understands it) need to
be looking at the HTML and/or javascript output from your servers and
sent to the browser to be interpreted/rendered/executed there.



Yes, but not in any way specific to your code. IE's famous memory leak
issue is caused by the existence of circular references between
javascript objects and COM object (which means DOM Nodes and ActiveX
objects). You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).



<snip>

Contrary to what Microsoft's documentation says, the memory leaks in
IE caused by circular references are not freed until IE is closed down.

reg:
You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).

Do you know how to do this? Do i just find the objects on unload and
set them to null? If so how can i find all the objects?

Can I write a general recursive function to kill all open circular
references on unload?

Thank you.

 

[Henry]

On Oct 3, 9:41 am, Henry wrote:



"reg"?

You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).

Do you know how to do this?

Yes, for code I can understand.

Do i just find the objects on unload and
set them to null?

Objects cannot be set to null. References to objects can be set to
null, and breaking circular chains of references usually involves
setting references to objects to null.

If so how can i find all the objects?

What objects?

Can I write a general recursive function to kill all open
circular references on unload?

Yes, but it is a very bad idea because it is very time consuming to
null all possible object references from all DOM Nodes and ActiveX
objects used (though some XML HTTP request systems would not leave the
request objects exposed so onunload cleanup would not be practical).
It is better to break only the circular references you mad in your
client-side code.

 

[Joshua]

Yes, for code I can understand.


Objects cannot be set to null. References to objects can be set to
null, and breaking circular chains of references usually involves
setting references to objects to null.


What objects?


Yes, but it is a very bad idea because it is very time consuming to
null all possible object references from all DOM Nodes and ActiveX
objects used (though some XML HTTP request systems would not leave the
request objects exposed so onunload cleanup would not be practical).
It is better to break only the circular references you mad in your
client-side code.

So how can you identify and kill a circular DOM reference? Any
ideas? Is there a link to something out there to some code samples?

 

[Joshua]

So how can you identify and kill a circular DOM reference? Any
ideas? Is there a link to something out there to some code samples?

It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.

Ajax is pretty, but always seems to cause more problems than it's
worth.

 

[David Mark]

It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.

And they don't break them on unload? If not, they are poorly written
widgets and you should stop using them.

Ajax is pretty, but always seems to cause more problems than it's
worth.

Your problem has nothing to do with Ajax. You are confusing Ajax with
DOM manipulation.

 

[Joshua]

Joshua said the following on 10/11/2007 1:30 PM:



What "ajax toolkit" are you using though? If removing the toolkit
removes the memory leak, then something in the toolkit is causing it and
if that is true, you need to contact the author of the library to find
out the best way to solve it. The best way to solve it is going to be to
correct it in the library itself.


Ajax may be, and may not be, the direct cause of your problem. The
biggest problem with "AJAX" (an XHR Request) is people not using it for
it's intended purpose.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ -http://jibbering.com/faq/index.html
Javascript Best Practices -http://www.JavascriptToolbox.com/bestpractices/

I'm simply using the most recent ajaxtoolkit dll downloaded from the
site as is. I have not made any modifications. This has been brought
up to the author (ms) and they have said that it does not exist.
However, if you use drip or sieve and simply navigate to their sample
web site, navigate to the calendar sample, click the calendar and
select a date, and then navigate away you will see 11 open DOM leaks
(each time you visit the page). And these are not deleted when you
reload, navigate away or unload. They are open DOM leaks that are not
able to be collected by the IE garbage collector until (of course) you
shut down the browser.

 

[Joshua]

Joshua said the following on 10/15/2007 11:49 AM:




Ummm. What "site" is that? I asked before and you haven't answered.


Is ms the author and is that Microsoft or some other ms?

Either way, if the leak exists with the ajaxtoolkit and doesn't exist
without it, then it is obvious that the problem is in the ajaxtoolkit.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ -http://jibbering.com/faq/index.html
Javascript Best Practices -http://www.JavascriptToolbox.com/bestpractices/

Try this:

http://asp.net/AJAX/AjaxControlToolkit/Samples/Calendar/Calendar.aspx

Go here (using sieve or drip), click the calendar icon, then navigate
away. That's the only test necessary.

 

[David Mark]

Try this:

http://asp.net/AJAX/AjaxControlToolkit/Samples/Calendar/Calendar.aspx

Looked pretty messed up in Windows Safari. Granted it is a Beta, but
I have never seen it render a widget quite this poorly (and I have
tested a lot of widgets on it.) I suspect it will have problems with
other browsers as well. It looked okay in IE7 and FF (though the
keyboard control didn't work in the latter.)

Go here (using sieve or drip), click the calendar icon, then navigate
away. That's the only test necessary.

Not exactly. That drip detector is not infallible. Considering that
Microsoft wrote the script, I suspect at least some of what it
reported is valid.