In June 2007, Microsoft famously fixed a problem with memory leaks in Internet Explorer 6. IE8 leaks memory worse than IE6 ever did, yet I haven’t been able to find any mention of it. I say worse because:
- No closures or circular references are required.
- I cannot find a workaround. (Update: See comments from May 9, 2011 for a way to avoid the problem.)
Update: It was fixed in IE10.
Problem statement
The memory used by IE8 to create certain DOM nodes is never freed, even if those DOM nodes are removed from the document (until window.top is unloaded). There are no closures or circular references involved.
The DOM node types that leak are form, button, input, select, textarea, a, img, and object. Most node types don’t leak, such as span, div, p, table, etc.
This problem only occurs in IE8 (and IE9 and IE10 preview). It does not occur in IE6, IE7, Firefox, or Chrome.
In case you missed it: every image element, anchor element, etc. added to a page uses memory that is not reclaimed even if the element is removed from the page.
In practical terms
Think intranet web application rather than Internet web site—that is, something that you may leave running for multiple days. If you have a web page that never reloads as a whole but pulls over many updates from the server (e.g., images and anchors are updated Ajax-style), each update will leak memory. Note that update here means existing DOM nodes are removed and new DOM nodes are created.
Depending on the size and frequency of the updates, IE8 can end up using all available virtual memory, start thrashing within itself, and eventually failures occur; see below for more details.
The user hitting F5 occasionally (if the page can handle it) will unload window.top and free its memory, but there is no apparent programmatic workaround. If the page is in an iframe, unloading the iframe has no effect. It seems that window.top must be unloaded.
In terms of code
First example
Here’s the basic idea of the leak, which is to repeatedly execute the following:
function leak1() {
var node = document.getElementById("TO_AREA");
node.innerHTML = "<img>";
node.innerHTML = "";
node = null;
}
Notes:
- You can leave off the second
innerHTMLassignment, as well as setting the node tonull, which I put in just for clarity/emphasis. - There’s an initially empty
divwith anidofTO_AREAin the body. - Example
innerHTMLthat doesn’t leak:<span></span>. See the problem statement above for a list of problematic node types. - As I mentioned, there are no closures or circular references involved here.
Second example
Here’s a similar piece of code that avoids innerHTML and has the same leak:
function leak2() {
var node = document.getElementById("FROM_AREA").cloneNode(true);
node.id = "NEW_AREA";
document.body.appendChild(node);
document.body.removeChild(node);
node = null;
}
Notes:
- The
FROM_AREAcontains HTML like in the first example. Still, there are no closures or circular references.
Third example
This is the simplest and most straightforward:
function leak4() {
var node = document.createElement("IMG");
document.body.appendChild(node);
document.body.removeChild(node);
}
Replace IMG with (e.g.) SPAN, and there is no leak.
Other notes
These examples leak in IE8 but not other browsers. I’ve tried IE8 on Windows XP, Windows Vista, Windows Server 2008, Windows Server 2008 R2, and Windows 7. I’ve tried IE in IE7 backwards compatibility mode, as well as every possible variation of quirks and standards mode. Though that’s by no means every variation of everything, it makes me comfortable that it’s not a fluke.
Live example
Here’s a link to an example page that shows the problem highly amplified. What I mean by amplified is that the job of the page is to show the leak, highly exacerbated; it has no other purpose. There are start/stop links on the page, so don’t worry about the page doing something terrible on its own.
http://test.hemiola.com/leak-ie8.html
Characterizing the leak
The memory size (called private working set on Windows 7) of iexplore.exe grows steadily over time, but this doesn’t lead directly to failures. IE memory usage does seem capped, and it does seem to be trying to manage memory from a DHTML perspective within certain constraints.
After it reaches its self-imposed cap, it seems to start thrashing within itself. Operations that could be performed at maybe 100 times per second begin taking over one minute per operation. Eventually, DHTML-style out-of-memory errors can occur.
In closing
I’m very interested in hearing about workarounds to this problem. I will post any meaningful updates as they are uncovered.
Update 2010-03-26
Microsoft made an IE9 preview available on 2010-03-16. It runs my leak test and does not leak. This is very promising. Additional update on 2010-06-24: We are now up to preview #3, and still no leaks.
There is a lot of memory churn in IE9 for the elements that leak in IE8, and there’s no churn at all for elements that don’t leak in IE8. The memory usage pattern in IE9 could be characterized as following a sawtooth pattern (low amplitude, high frequency), but with no long-term growth. I ran the test for an hour with no memory growth in IE9, whereas IE8 grew by about 1 GB in the same time.
Update 2010-09-16
Microsoft released the first beta of IE9 yesterday. The leak is back, at a rate of about 1 GB an hour: the same elements are leaking as before, at about the same rate as before.
Update 2010-10-28
Microsoft released the sixth preview of IE9 today. The leak is still there, same as in the beta.
Update 2010-11-17
Microsoft released the seventh preview of IE9 today. There’s the same churn and sawtooth as in the original three previews, and likewise, there is no leak. This is turning into a nail-biter.
Update 2011-02-10
Microsoft released the IE9 RC today. The leak is back.
Update 2011-03-14
Today is π Day, and Microsoft released IE9. The leak is still there.
Update 2011-04-12
Microsoft released IE10 Platform Preview 1. In terms of leaking, this is very similar to the IE9 preview: no overall leak, but a lot of churn and the sawtooth pattern is back.
Update 2011-06-29
Microsoft released IE10 Platform Preview 2. No leak. I suppose there is no SmartScreen Filter in these preview releases, which might account for the leak being absent from them.
Update 2011-09-13
Microsoft released the IE10 Platform Preview 3 as part of the Windows 8 Developer Preview. The leak is still there if the SmartScreen Filter is off; otherwise (the default), the leak is not there.
Update 2011-11-29
Microsoft released the IE10 Platform Preview 4 for the Windows 8 Developer Preview. The leak is not there, but I suspect the SmartScreen Filter is also not there; it’s hard to tell.
Update 2012-02-29
Microsoft released the IE10 Platform Preview 5 for the Windows 8 Consumer Preview. The leak is not there, and the SmartScreen Filter definitely is. This is the best it’s looked in years.
Update 2012-05-31
Microsoft released the IE10 Platform Preview 6 for the Windows 8 Release Preview. The leak is not there, and the SmartScreen Filter definitely is. This is the best IE has looked in years. And Windows 8 is looking pretty good, too (after going to the desktop and staying there, that is).
Update 2012-11-13
Microsoft released the release preview of IE10 for Windows 7. The leak is back, just as before: with the SmartScreen Filter disabled, the leak is present; with the SmartScreen Filter enabled, the leak is not present.
Update 2013-02-26
Microsoft released IE10 on Windows 7. The leak is gone! With the SmartScreen Filter enabled, the sawtooth pattern is there. With the SmartScreen Filter disabled, it looks even better: no manic memory usage and no memory growth.
Update 2013-06-26
Microsoft released an IE11 Preview with the Windows 8.1 Preview. I haven’t had a chance to look at it.
Update 2013-07-25
Microsoft released the Developer Preview of IE11 for Windows 7. It looks fine.
Leave a Reply