Hi all,
I've been trying to pin down a memory leak in IE6 for several WEEKS
now. I've done my share of googling etc., and know all about common
leaks like circular references and closures, but have found nothing like
this.
This app is designed to run in a kiosk environment, so it has
things like a persistent frame which holds data as well as the visible
frame (actually an iframe). After 1,000 page transitions our app is up
by almost 20MB; considering kiosks can run for days or even weeks this
is definitely not ideal. There's definitely a lot of stuff happening,
but I've managed to pin the leak down to a very odd case.
I have two identical test pages which I click between using a
navigate() function. I am absolutely sure that the tags in question have
their event handlers set to null before the page is navigated away from.
The following shows the leak (apologies, my news server disallows
HTML tags):
[a onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following does NOT leak (there's a small leak but nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following DOES leak:
[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
Does anyone have any clue why this might be, ignoring the mass of
code that gets executed on page load/unload? Why would clicking that
link not leak only when there's an href assigned? Does that do something
weird to the event bubbling, perhaps? Or fire an extra event (or *not*
fire some other event)? And why wouldn't the magic also trip when
location.href is assigned via JavaScript?
Anyone who has any idea about this is invited to make my life a lot
happier. Thanks very much!
--Daniel Orner
18  2118 
Wouldn't the "location.href='#'" reload the page, thereby reinitialize
any event handlers you have in your code? What does "navigate()" do,
besides the obvious I mean...
kit.ludwick wrote:
Wouldn't the "location.href='#'" reload the page, thereby reinitialize
any event handlers you have in your code? What does "navigate()" do,
besides the obvious I mean...
No, I tried it and it doesn't reload the page, at least on IE6. And if
it did, the same thing would have happened in the onmousedown handler,
and yet they act differently.
The navigate() basically moves to the next page. Like I said, there's a
lot of stuff going on there (there are several frames/iframes involved),
but I'd like to concentrate on the difference between adding an href='#'
attribute and removing it.
kit.ludwick wrote:
Wouldn't the "location.href='#'" reload the page, [...]
Of course not. Read RFC3986.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Daniel Orner wrote:
I have two identical test pages which I click between using a
navigate() function. I am absolutely sure that the tags in question have
their event handlers set to null before the page is navigated away from.
The following shows the leak (apologies, my news server disallows
HTML tags):
Find a better server. aioe.org is, due to its lack of policy, a home for
spammers and trolls to begin with, and filtered by some people and servers
because of this.
[a onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following does NOT leak (there's a small leak but nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following DOES leak:
[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
Does anyone have any clue why this might be, ignoring the mass of
code that gets executed on page load/unload?
Chances are something else happens than posted here. Not all event
listeners are obvious from the markup. In fact, some people, particularly
clueless authors and users of libraries, like to obfuscate their
applications by using scripting methods to add event listeners when there is
no need for that, calling such atrocities "Unobtrusive JavaScript" then.
Makes it a PITA to debug the application every time.
Then again, IE 6 is a piece of outdated junk. I'm looking forward to its
end-of-life.
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>
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
> I have two identical test pages which I click between using a
navigate() function. I am absolutely sure that the tags in question have
their event handlers set to null before the page is navigated away from.
The following shows the leak (apologies, my news server disallows
HTML tags):
Find a better server. aioe.org is, due to its lack of policy, a home for
spammers and trolls to begin with, and filtered by some people and servers
because of this.
>[a onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following does NOT leak (there's a small leak but nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following DOES leak:
[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
Does anyone have any clue why this might be, ignoring the mass of
code that gets executed on page load/unload?
Chances are something else happens than posted here. Not all event
listeners are obvious from the markup. In fact, some people, particularly
clueless authors and users of libraries, like to obfuscate their
applications by using scripting methods to add event listeners when there is
no need for that, calling such atrocities "Unobtrusive JavaScript" then.
Makes it a PITA to debug the application every time.
Then again, IE 6 is a piece of outdated junk. I'm looking forward to its
end-of-life.
PointedEars
Can't argue there. -_- It'll be quite a while though, especially in my
line of work.
I have a cleanup function that runs and gets rid of the event handlers
on page unload. I've also installed the latest IE patch (April 2008)
that *supposedly* renders those issues moot.
There certainly is more stuff happening on navigation, but I'm more
concerned about the difference in behavior from adding the href='#' and
leaving it out... if I could understand that maybe I could mimic that
behavior in the real app.
In any case, I'm not doing anything with those tags other than what's
hardcoded in them plus removing the event handlers on page unload. So
unless the Prototype library manually seeks out every tag on the page
and does stuff to them (which I highly doubt) that wouldn't have
anything to do with it.
Thanks for your feedback!
--Daniel
Daniel Orner wrote:
Thomas 'PointedEars' Lahn wrote:
>Daniel Orner wrote:
>> The following does NOT leak (there's a small leak but nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following DOES leak:
[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
Does anyone have any clue why this might be, ignoring the mass of
code that gets executed on page load/unload?
Chances are something else happens than posted here. Not all event
listeners are obvious from the markup. In fact, some people, particularly
clueless authors and users of libraries, like to obfuscate their
applications by using scripting methods to add event listeners when there is
no need for that, calling such atrocities "Unobtrusive JavaScript" then.
Makes it a PITA to debug the application every time.
[...]
[...]
In any case, I'm not doing anything with those tags other than what's
hardcoded in them plus removing the event handlers on page unload. So
unless the Prototype library manually seeks out every tag on the page
and does stuff to them (which I highly doubt) that wouldn't have
anything to do with it.
Prototype.js is junk, and an example of the libaries I mentioned above, so
all bets are off. Dump it and a lot of problems will go away.
Please trim your quotes.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
>Thomas 'PointedEars' Lahn wrote:
>>Daniel Orner wrote:
The following does NOT leak (there's a small leak but nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following DOES leak:
[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
Does anyone have any clue why this might be, ignoring the mass of
code that gets executed on page load/unload?
Chances are something else happens than posted here. Not all event
listeners are obvious from the markup. In fact, some people, particularly
clueless authors and users of libraries, like to obfuscate their
applications by using scripting methods to add event listeners when there is
no need for that, calling such atrocities "Unobtrusive JavaScript" then.
Makes it a PITA to debug the application every time.
[...]
[...]
In any case, I'm not doing anything with those tags other than what's
hardcoded in them plus removing the event handlers on page unload. So
unless the Prototype library manually seeks out every tag on the page
and does stuff to them (which I highly doubt) that wouldn't have
anything to do with it.
Prototype.js is junk, and an example of the libaries I mentioned above, so
all bets are off. Dump it and a lot of problems will go away.
Please trim your quotes.
PointedEars
Thanks for the tip. I did look at the quotes but thought that they were
all relevant to my reply.
Unfortunately, getting rid of Prototype will be difficult at this
point. Even if Prototype was the culprit, however, that still doesn't
answer the question of why the leak doesn't happen when I add that
"href" attribute to the link. That's what I'm most concerned about.
On Nov 19, 5:38*pm, Daniel Orner <dor...@ca.ibm.comwrote:
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
* * *The following does NOT leak (there's a small leak but nowhere near
as much):
>>[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
>>* * *The following DOES leak:
>>[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
>>* * *Does anyone have any clue why this might be, ignoring themass of
code that gets executed on page load/unload?
Chances are something else happens than posted here. *Not all event
listeners are obvious from the markup. *In fact, some people, particularly
clueless authors and users of libraries, like to obfuscate their
applications by using scripting methods to add event listeners when there is
no need for that, calling such atrocities "Unobtrusive JavaScript" then.
Makes it a PITA to debug the application every time.
[...]
[...]
* * * *In any case, I'm not doing anything with those tags other than what's
hardcoded in them plus removing the event handlers on page unload. So
unless the Prototype library manually seeks out every tag on the page
and does stuff to them (which I highly doubt) that wouldn't have
anything to do with it.
Prototype.js is junk, and an example of the libaries I mentioned above,so
all bets are off. *Dump it and a lot of problems will go away.
Please trim your quotes.
PointedEars
* * * * Thanks for the tip. I did look at the quotes but thought that they were
all relevant to my reply.
* * * * Unfortunately, getting rid of Prototype will be difficultat this
point. Even if Prototype was the culprit, however, that still doesn't
See what you did? Great way to save time.
answer the question of why the leak doesn't happen when I add that
"href" attribute to the link. That's what I'm most concerned about.
Why?
Daniel Orner wrote:
* * *I've been trying to pin down a memory leak in IE6 for several WEEKS
now. I've done my share of googling etc., and know all about common
leaks like circular references and closures, but have found nothing like
this.
* * *This app is designed to run in a kiosk environment, so it has
things like a persistent frame which holds data as well as the visible
frame (actually an iframe). After 1,000 page transitions our app is up
by almost 20MB; considering kiosks can run for days or even weeks this
is definitely not ideal.
A webpage that keeps in the memory for days/weeks, should preferably
use scarce client side scripting.
There's definitely a lot of stuff happening, but I've managed to pin
the leak down to a very odd case.
* * *I have two identical test pages which I click between using a
navigate() function. I am absolutely sure that the tags in question have
their event handlers set to null before the page is navigated away from.
* * *The following shows the leak (apologies, my news server disallows
HTML tags):
[a onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
* * *The following does NOT leak (there's a small leak but nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
* * *The following DOES leak:
[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
Your code is the same as:
<a href="testPage2.html" target="xx">CLICK ME</a>
If you need additional code in your 'navigate()'-function, it could be
placed in an 'onLoad'-event of the body of testPage2.html, or
alternatively in an 'onClick'-event of the same <a>:
<a href="testPage2.html" target="xx" onClick="...">CLICK ME</a>
The 'onLoad' is maybe better because it is a fresh page. And I like
onClick more than onMouseDown, but that is probably a personal
preference nowadays.
* * *Does anyone have any clue why this might be, ignoring the massof
code that gets executed on page load/unload? Why would clicking that
link not leak only when there's an href assigned? Does that do something
weird to the event bubbling, perhaps? Or fire an extra event (or *not*
fire some other event)? And why wouldn't the magic also trip when
location.href is assigned via JavaScript?
The reason for the leak is impossible to determine, as it is MSIE
source code. My best bet goes to MS coders who assumed that there will
always be a href-attribute if an <a>-tag holds an onMouseDown, and
they overlooked the possibility if that were different.
Microsoft's JScript knows the unofficial and undocumented
'CollectGarbage()'. Maybe it could help in this case, but it's better
to avoid it when possible. http://groups.google.com/group/comp....3c7c11f20ad185
In your type of application (Kiosk), I suppose you should have the
possibility to update to MSIE 7/8. That could maybe solve the problem
as well.
Anyway, your posted code is a bit unusual and awkward IMHO. I would
rewrite it.
Hope this helps,
--
Bart
David Mark wrote:
On Nov 19, 5:38 pm, Daniel Orner <dor...@ca.ibm.comwrote:
>Thomas 'PointedEars' Lahn wrote:
>>Daniel Orner wrote:
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
> The following does NOT leak (there's a small leak but nowhere near
>as much):
>[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
> The following DOES leak:
>[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]
> Does anyone have any clue why this might be, ignoring the mass of
>code that gets executed on page load/unload?
<SNIP>
>
>answer the question of why the leak doesn't happen when I add that
"href" attribute to the link. That's what I'm most concerned about.
Why?
Because if I could isolate that behavior and somehow apply it to my
other tags, it would immediately fix the problem without forcing me to
go back and totally redo half my code. There are parts of Prototype I
use extensively which would be very hard to do without.
Bart Van der Donck wrote:
>
A webpage that keeps in the memory for days/weeks, should preferably
use scarce client side scripting.
Unfortunately it's difficult to work around that while still doing
browser-based apps. Part of the problem is trying to balance the
necessity of contacting the server with the complexity of the client code.
>
>There's definitely a lot of stuff happening, but I've managed to pin
the leak down to a very odd case.
I have two identical test pages which I click between using a
navigate() function. I am absolutely sure that the tags in question have
their event handlers set to null before the page is navigated away from.
The following shows the leak (apologies, my news server disallows
HTML tags):
[a onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following does NOT leak (there's a small leak but nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following DOES leak:
[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK
ME[/a]
>
Your code is the same as:
[a href="testPage2.html" target="xx"]CLICK ME[/a]
I thought "target" indicated which window frame to click into? How is
that the same as my code? And which one is the same as that? The one
that does leak or the one that doesn't?
>
If you need additional code in your 'navigate()'-function, it could be
placed in an 'onLoad'-event of the body of testPage2.html, or
alternatively in an 'onClick'-event of the same [a]:
[a href="testPage2.html" target="xx" onClick="..."]CLICK ME[/a]
What's the difference between onmousedown and onClick? I'm not sure I
get this.
>
The 'onLoad' is maybe better because it is a fresh page. And I like
onClick more than onMouseDown, but that is probably a personal
preference nowadays.
onClick is unfortunately not usable in a kiosk environment with a touch
screen where inadvertent mouse drags might mess it up.
>
> Does anyone have any clue why this might be, ignoring the mass of
code that gets executed on page load/unload? Why would clicking that
link not leak only when there's an href assigned? Does that do something
weird to the event bubbling, perhaps? Or fire an extra event (or *not*
fire some other event)? And why wouldn't the magic also trip when
location.href is assigned via JavaScript?
The reason for the leak is impossible to determine, as it is MSIE
source code. My best bet goes to MS coders who assumed that there will
always be a href-attribute if an [a]-tag holds an onMouseDown, and
they overlooked the possibility if that were different.
Microsoft's JScript knows the unofficial and undocumented
'CollectGarbage()'. Maybe it could help in this case, but it's better
to avoid it when possible.
http://groups.google.com/group/comp....3c7c11f20ad185
I don't think that's the issue... we do long-running tests and
doubtless the garbage collection happens at least at the end of it. I'll
give it a try though... thanks for the tip.
>
In your type of application (Kiosk), I suppose you should have the
possibility to update to MSIE 7/8. That could maybe solve the problem
as well.
Unfortunately we don't own the kiosks and can't demand this of the
operators.
>
Anyway, your posted code is a bit unusual and awkward IMHO. I would
rewrite it.
The posted code is a very simple test; it isn't what we'd actually use.
I'm just trying to analyze it, particularly why that "href='#'" suddenly
causes the leak to go away.
Thanks very much for the help!
Daniel Orner wrote:
Bart Van der Donck wrote:
>Daniel Orner wrote:
>>[a onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
[a onmousedown="location.href='#';navigate('testPage2 .html');"]
CLICK ME[/a]
Your code is the same as:
* [a href="testPage2.html" target="xx"]CLICK ME[/a]
* * * * I thought "target" indicated which window frame to click into? How is
that the same as my code? And which one is the same as that? The one
that does leak or the one that doesn't?
It is identical to the three (I assume that your 'navigate()' modifies
the location of another frame).
The target-attribute specifies in which frame or window the link
should be opened.
Suppose your page has 2 frames, one <frame name="upperframe"
src="1.htm"and the other <frame name="lowerframe" src="2.htm">, then
a line <a href="3.htm" target="lowerframe">click</ainside the upper
frame will open in the lower frame. The content of upper frame remains
identical in this case, unless, for example, 3.htm holds a <body
onLoad=""with an instruction to alter the location of the upper
frame.
>* [a href="testPage2.html" target="xx" onClick="..."]CLICK ME[/a]
* * * *What's the difference between onmousedown and onClick? I'mnot sure I
get this.
'onClick' has stronger historical roots, but I think it actually
doesn't matter.
*The 'onLoad' is maybe better because it is a fresh page. And I like
*onClick more than onMouseDown, but that is probably a personal
*preference nowadays.
* * * * onClick is unfortunately not usable in a kiosk environment with a touch
screen where inadvertent mouse drags might mess it up.
I see. Then you can of course not use 'onClick'.
>Microsoft's JScript knows the unofficial and undocumented
'CollectGarbage()'. Maybe it could help in this case, but it's better
to avoid it when possible.
* * * * I don't think that's the issue... we do long-running tests and
doubtless the garbage collection happens at least at the end of it. I'll
give it a try though... thanks for the tip.
You're welcome. But I doubt if it will help.
--
Bart
Daniel Orner wrote:
David Mark wrote:
>On Nov 19, 5:38 pm, Daniel Orner <dor...@ca.ibm.comwrote:
>>Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
Thomas 'PointedEars' Lahn wrote:
>Daniel Orner wrote:
>> The following does NOT leak (there's a small leak but
>>nowhere near
>>as much):
>>[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
>> The following DOES leak:
>>[a
>>onmousedown="location.href='#';navigate('tes tPage2.html');"]CLICK
>>ME[/a]
>> Does anyone have any clue why this might be, ignoring the
>>mass of
>>code that gets executed on page load/unload?
<SNIP>
>>
>>answer the question of why the leak doesn't happen when I add that
"href" attribute to the link. That's what I'm most concerned about.
Why?
Because if I could isolate that behavior and somehow apply it to my
other tags, it would immediately fix the problem without forcing me to
go back and totally redo half my code. There are parts of Prototype I
use extensively which would be very hard to do without.
This is a long shot. And shoot me down, but possibly what is happening
is that a succession of windows opening in different targets are causing
an excessive amount of window objects to build up in the browser.
Windows that are closed, are not 'destroyed', merely *marked as closed*.
I try to always re-use window targets for this reason, and to also not
proliferate too many popups
On Nov 20, 6:49*pm, The Natural Philosopher <a...@b.cwrote:
[snip]
This is a long shot. And shoot me down, but possibly what is happening
No.
Daniel Orner wrote:
Thomas 'PointedEars' Lahn wrote:
>Daniel Orner wrote:
>>In any case, I'm not doing anything with those tags other than what's
hardcoded in them plus removing the event handlers on page unload.
So unless the Prototype library manually seeks out every tag on the
page and does stuff to them (which I highly doubt) that wouldn't have
anything to do with it.
Prototype.js is junk, and an example of the libaries I mentioned above,
so all bets are off. Dump it and a lot of problems will go away.
Please trim your quotes.
PointedEars
Thanks for the tip.
Which tip? (See?)
I did look at the quotes but thought that they were all relevant to my
reply.
To begin with, how is my signature relevant to your reply? You have posted
without using /dev/brain, period. And you did it again.
And even if all of the quoted text is relevant, it is allowed, and asked
for, to [summarize] the quotation in keeping with its meaning so as to ease
reading.
Read the FAQ. <http://jibbering.com/faq/#posting>
Unfortunately, getting rid of Prototype will be difficult at this point.
No, it won't. Unless you did not know what you were doing in the first
place, of course, in which case you would get what you deserve.
Even if Prototype was the culprit,
Bad code does bad things. No doubt about that.
however, that still doesn't answer the question of why the leak doesn't
happen when I add that "href" attribute to the link.
Yes, it would. Prototype.js uses a lot of closures which create circular
references, many of them unnecessary, which are known to leak memory in IE
if host objects (here: DOM objects) are involved (because its GC can't
handle that), and it does not clean up after itself. Adding the `href'
attribute to the `a' element makes it a link in the first place, so that its
corresponding object shows up in the document.links NodeList, for example.
Read the FAQ Notes. <http://jibbering.com/faq/faq_notes/closures.html#clMem>
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
The Natural Philosopher wrote:
Daniel Orner wrote:
> The following does NOT leak (there's a small leak but
nowhere near
as much):
[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]
The following DOES leak:
[a
onmousedown="location.href='#';navigate('testPage 2.html');"]CLICK
ME[/a]
Does anyone have any clue why this might be, ignoring the
mass of
code that gets executed on page load/unload?
<SNIP>
>>>
answer the question of why the leak doesn't happen when I add that
"href" attribute to the link. That's what I'm most concerned about.
Why?
Because if I could isolate that behavior and somehow apply it to
my other tags, it would immediately fix the problem without forcing me
to go back and totally redo half my code. There are parts of Prototype
I use extensively which would be very hard to do without.
This is a long shot. And shoot me down, but possibly what is happening
is that a succession of windows opening in different targets are causing
an excessive amount of window objects to build up in the browser.
Windows that are closed, are not 'destroyed', merely *marked as closed*.
I try to always re-use window targets for this reason, and to also not
proliferate too many popups
No, I'm not using any popups nor opening windows. Thanks for the
attempt though. 8-)
Thomas 'PointedEars' Lahn wrote:
<snip>
>
Yes, it would. Prototype.js uses a lot of closures which create circular
references, many of them unnecessary, which are known to leak memory in IE
if host objects (here: DOM objects) are involved (because its GC can't
handle that), and it does not clean up after itself. Adding the `href'
attribute to the `a' element makes it a link in the first place, so that its
corresponding object shows up in the document.links NodeList, for example.
Read the FAQ Notes. <http://jibbering.com/faq/faq_notes/closures.html#clMem>
This sounds promising... however, it seems to work backwards from my
understanding. I thought that the memory leak happens when a DOM node
has a circular reference to a JavaScript object. You seem to be saying
that when a link is created, it's added to document.links... wouldn't
that then mean that the link would have *more* references than non-links
and hence be *more* likely to leak, rather than stop leaking? Or is
there something I'm not understanding properly?
Thanks for your help.
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
>Thomas 'PointedEars' Lahn wrote:
<snip>
>>Prototype.js uses a lot of closures which create circular
references, many of them unnecessary, which are known to leak memory in IE
if host objects (here: DOM objects) are involved (because its GC can't
handle that), and it does not clean up after itself. Adding the `href'
attribute to the `a' element makes it a link in the first place, so that its
corresponding object shows up in the document.links NodeList, for example.
[Read the FAQ Notes. <http://jibbering.com/faq/faq_notes/closures.html#clMem>
[...] I thought that the memory leak happens when a DOM node
has a circular reference to a JavaScript object. You seem to be saying
that when a link is created, it's added to document.links... wouldn't
that then mean that the link would have *more* references than non-links
and hence be *more* likely to leak, rather than stop leaking? Or is
there something I'm not understanding properly?
Chances are that Prototype.js uses document.links or a similar NodeList in a
closure and adds event listeners with scripting. The uncleaned circular
references to the NodeList or an element of that list would leak memory in
IE. That effect could then only be observed if the event target results in
an element of such a NodeList, i.e. if you make that possible by adding the
`href' attribute.
This is nothing but conjecture, of course. Only a look at the source code
can provide a definitive answer.
Thanks for your continuing help with this, and apologies for my newness
to the rules of this newsgroup. Doubtless I'll stumble again, so your
patience is appreciated.
Maybe I'm being dense, but I still think I'm missing something. Your
explanation seems to indicate that when the tag in question is a link,
that something in the library might add an event to the document.links
list, and that event would leak. However, I'm seeing the opposite - when
the tag is a link, it *doesn't* leak. It's only when it isn't a link
that the leak occurs.
Something else occurred to me, too... doesn't IE6 have a document.all
NodeList in any case? So why would it matter if it's a link or not?
I double-checked the Prototype source code and the word "link" doesn't
occur anywhere inside it, so it isn't doing anything with document.links
(and neither am I)... This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ranjeet.gupta |
last post by:
Dear All
Is the Root Cause of the Memory corruption is the Memory leak, ??
suppose If in the code there is Memory leak, Do this may lead to the
Memory Corruption while executing the program ?
...
|
by: José Joye |
last post by:
Hi,
I have implemented a Service that is responsible for getting messages from a
MS MQ located on a remote machine. I'm getting memory leak from time to time
(???). In some situation, it is...
|
by: Don Nell |
last post by:
Hello
Why is there a memory leak when this code is executed.
for(;;)
{
ManagementScope scope = new ManagementScope();
scope.Options.Username="username";
scope.Options.Password="password";...
|
by: jeevankodali |
last post by:
Hi
I have an .Net application which processes thousands of Xml nodes each
day and for each node I am using around 30-40 Regex matches to see if
they satisfy some conditions are not. These Regex...
|
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
|
by: Adrian |
last post by:
Hi
I have a JS program that runs localy (under IE6 only) on a PC but it has
a memory leak (probably the known MS one!)
What applications are there that I could use to look at the memory usage of...
|
by: Salvador |
last post by:
Hi,
I am using WMI to gather information about different computers (using win2K
and win 2K3), checking common classes and also WMI load balance. My
application runs every 1 minute and reports...
|
by: Jim Land |
last post by:
Jack Slocum claims here
http://www.jackslocum.com/yui/2006/10/02/3-easy-steps-to-avoid-javascript-
memory-leaks/
that "almost every site you visit that uses JavaScript is leaking memory".
...
|
by: Peter |
last post by:
I am using VS2008.
I have a Windows Service application which creates Crystal Reports. This is
a multi theaded application which can run several reports at one time.
My problem - there is a...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
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...
|
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
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
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...
|
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,...
|
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: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
