Closed GoogleCodeExporter closed 9 years ago
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 marekr...@gmail.com
on 1 Jul 2008 at 10:18
here is more:
http://msdn.microsoft.com/en-us/library/bb250448.aspx
Original comment by marekr...@gmail.com
on 1 Jul 2008 at 10:57
[deleted comment]
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 aeron.gl...@gmail.com
on 26 Jul 2008 at 7:53
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 aeron.gl...@gmail.com
on 19 Oct 2008 at 6:46
Original issue reported on code.google.com by
marekr...@gmail.com
on 1 Jul 2008 at 10:11