INTERNET EXPLORER - MEMORY LEAK !!!

[GoogleCodeExporter]

INTERNET EXPLORER - MEMORY LEAK !!!

[GoogleCodeExporter]

Maybe this Issue?

The Internet Explorer Memory Leak Problem

The Internet Explorer web browser (verified on versions 4 to 6 (6 is current at 
the
time of writing)) has a fault in its garbage collection system that prevents it 
from
garbage collecting ECMAScript and some host objects if those host objects form 
part
of a "circular" reference. The host objects in question are any DOM Nodes 
(including
the document object and its descendants) and ActiveX objects. If a circular 
reference
is formed including one or more of them, then none of the objects involved will 
be
freed until the browser is closed down, and the memory that they consume will be
unavailable to the system until that happens.

A circular reference is when two or more objects refer to each other in a way 
that
can be followed and lead back to the starting point. Such as object 1 has a 
property
that refers to object 2, object 2 has a property that refers to object 3 and 
object 3
has a property that refers back to object 1. With pure ECMAScript objects as 
soon as
no other objects refer to any of objects 1, 2 or 3 the fact that they only 
refer to
each other is recognised and they are made available for garbage collection. 
But on
Internet Explorer, if any of those objects happen to be a DOM Node or ActiveX 
object,
the garbage collection cannot see that the circular relationship between them is
isolated from the rest of the system and free them. Instead they all stay in 
memory
until the browser is closed.

Closures are extremely good at forming circular references. If a function 
object that
forms a closure is assigned as, for example, and event handler on a DOM Node, 
and a
reference to that Node is assigned to one of the Activation/Variable objects in 
its
scope chain then a circular reference exists. DOM_Node.onevent ->
function_object.[[scope]] -> scope_chain -> Activation_object.nodeRef -> 
DOM_Node. It
is very easy to do, and a bit of browsing around a site that forms such a 
reference
in a piece of code common to each page can consume most of the systems memory
(possibly all).

Care can be taken to avoid forming circular references and remedial action can 
be
taken when they cannot otherwise be avoided, such as using IE's onunload event 
to
null event handling function references. Recognising the problem and 
understanding
closures (and their mechanism) is the key to avoiding this problem with IE. 

Original comment by [email protected] on 1 Jul 2008 at 10:18

[GoogleCodeExporter]

here is more:
http://msdn.microsoft.com/en-us/library/bb250448.aspx

Original comment by [email protected] on 1 Jul 2008 at 10:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Regarding the memory leak, the Mootools framework does the work of cleaning up 
after
IE's leakiness. However it looks as thought there's a problem with the Morph 
class
(which Slideshow uses extensively):

http://mootools.lighthouseapp.com/projects/2706/tickets/57-ie-leak-on-morph

As soon as it's fixed in the framework it should no longer be a problem with 
Slideshow.

Original comment by [email protected] on 26 Jul 2008 at 7:53

• Changed state: Accepted

[GoogleCodeExporter]

This bug no longer appears in Lighthouse - i'm going to assume it's resolved in
Mootools 1.2.1 unless someone can duplicate it - thank you.

Original comment by [email protected] on 19 Oct 2008 at 6:46

• Changed state: WontFix