Tools for Detecting Memory Leaks
Hi everyone,
As many web devs know, it’s relatively easy to build a site which results in memory leaks when viewed in Internet Explorer. IE team members have written MSDN articles on leak patterns, and other sites have posted articles with varying tone, depending on the author’s frustration with the problem.
These memory leaks often occur as a result of circular references between Jscript objects and objects within IE’s DOM (document object model). Since the Jscript engine and IE have independent memory management schemes, each side can’t see the entire cycle of these circular references.
Internet Explorer 7 improved the situation by releasing all references to Jscript objects attached to the DOM tree when IE navigates away from that page. This allows the Jscript engine to then garbage collect those Jscript objects and recover that memory. We’ve also made the same changes in IE6 on Windows XP SP2 (shipped originally with the June Update). However, as some web developers have pointed out, those changes don’t solve the problem entirely. IE still leaves behind anything not attached to the tree when we tear down the markup. In addition, sites that users keep open for extended periods of time, such as Web-based mail, can still cause IE’s memory usage to continually grow if the site doesn’t take care to avoid the leak patterns.
So no, it’s not perfect, but we’re also continuing to invest in improvements for future versions of IE.
In the meantime, tools and best practices can help web developers find and remove leaks today.
Drip and sIEve (joint SourceFourge site) are two such tools. Many of you may already be familiar with them, but a little extra visibility never hurts. Both applications host Trident – IE’s rendering engine – and add detection of memory leak patterns. They let you track memory and DOM usage while using a site and then detect any leaks when you navigate away from that page. Drip is an open source project under the BSD license. Based on Drip, sIEve improves the usability in a few ways including non-modal dialogs and a real-time graph of DOM usage instead of memory usage. If you have questions/comments about the tools themselves, try the documentation, forum, or mailing list. And if you’re interested in taking a more active role in the project, contact Matthias Miller through the forum or mailing list.
Those tools will you help find the leaks, and here are a few articles that provide more information about removing them, or better yet, avoiding them in the first place:
- “Understanding and Solving Internet Explorer Leak Patterns”
- “Fixing Leaks”
- “Memory Leakage in Internet Explorer – revisited”
Thanks!
John Hrvatin
Program Manager
Internet Explorer
Comments
Anonymous
November 29, 2007
Any status on the public bug tracking?!Anonymous
November 29, 2007
Tried the Firefox 3 beta yet? When will there be a beta for IE8?Anonymous
November 29, 2007
Fx 3 beta 2 still have memory problem, worse than IE7. @John, Thanks for the detial but as Frank said we may need bug tracking (may be on connect) to report the bug or track on situation of reported bug. I think it not bad idea. Btw, people want to know something about what going on with IE8. For the promised of 12-18 month from the begining we should have some things around here.Anonymous
November 29, 2007
n-blue, there is no Firefox 3 beta 2 yet so I doubt that it true. At least Mozilla is releasing something after a year. Hello IE?Anonymous
November 29, 2007
The comment has been removedAnonymous
November 29, 2007
I've been aware of Drip from quite some time and it is very useful! But I didn't know about sIEve and it seems even nicer.. So thanks very much! PS: However, please please try to fix these leaks in IE8!Anonymous
November 30, 2007
Thanks for the tips on Sieve! It is much better than drip, which can make it quite difficult to detect where the leaks are occurring. I also with Frank n-Blue and Un-blue on the bug tracking. Seriously guys! Since you can't meet the release cycle you guys promised you would, the least you can offer is a bug tracking system so we can see what is going on! In IE8, am I still going to have to write craptacular code like this? //only for IE var sendButton = document.createElement('<input name="sendit"/>'); sendButton.setAttribute('type', 'button');//can't set it after you add it to the DOM! sendButton.setAttribute('value', 'Send It'); customXBAddDOMEventHandler('click', mySendItHandler); var myFormObj = document.getElementsById('myForm'); myFormObj.appendChild(sendButton); For adding this 1 button to a page, I need to work around at least 5 separate IE bugs! Not laughing at the lack of bug tracking anymore. It shows a complete lack of respect to your fellow developers using IE.Anonymous
November 30, 2007
Well, since the IE6 fix is only available for XPSP2, there is little point to the fix. make it win2K compliant or better, release IE7 for win2K and give up on IE6.Anonymous
November 30, 2007
Laurent, There will never be an IE7 for Win2K. This was discussed, oh, two years ago?Anonymous
December 01, 2007
The comment has been removedAnonymous
December 01, 2007
you are right pinto, looks like they are doing a #2.Anonymous
December 02, 2007
Any roadmap for the release of IE8. Firefox already has an FF 3.0 alpha.Anonymous
December 02, 2007
Memory leaks? Wasn't that problem solved with .Net and Garbage Collecor? Oh!? IETeam doesn't know about .Net? Well... I guess it was reseased after IETeam stopped working in 2002. Go check microsoft.com. They have some info on it.Anonymous
December 02, 2007
The comment has been removedAnonymous
December 07, 2007
I still feel that Memory leaks is something which is really taking down the popularity of IE.Anonymous
December 08, 2007
Seriously guys! Since you can't meet the release cycle you guys promised you would, the least you can offer is a bug tracking system so we can see what is going on! :SAnonymous
December 10, 2007
We at FCKeditor are constantly fighting against memory leak. We have already fixed several related issues, but we were still facing an expressive memory leak with IE7. With some intuition, we were able to reduce the problem to a simple test case, and we have sadly found a new memory leak issue introduced with IE7. Essentially, every call to window.createPopup() leaks 80Kb of memory. A test page can be found here: http://www.fredck.com/bugs/ie/createpopupleak.html In the default FCKeditor interface, we use six IE's popups for all floating panels (toolbar combos and context menu). On pages with several editor instances, the memory increasing is substantial. As far as we could understand it, there is no way to "cleanup" that leak. We strongly hope IE8 and even IE7 will have it fixed as there is no way to workaround it (I hope I'm wrong!). Suggestions? Comments?Anonymous
December 12, 2007
@fredck - You'll probably get dozens of comments to this effect, but window.createPopup is so Web 1.0 anyway. The "new approach" is to use positioned divs with z-indexes to create the illusion of a new window, but everything still exists within the same window. This also prevents popup blockers from preventing users (at least initially, until they've told their browser to allow popups from the current site) from using the feature that would otherwise load in a separate window. Check out the way ExtJS handles this for an elegant example.Anonymous
December 12, 2007
@Tim I'm sorry, but that's not the point. The point is that this is a new leak, introduced in IE7. And to tell the truth, I don't care how "Web 1.0" something is - not every project has the money, time, or ability to upgrade legacy applications to use a different javascript toolkit. Many older applications make use of window.createPopup(), and a leak in such a core function is absolutely unacceptable.Anonymous
December 12, 2007
The comment has been removedAnonymous
December 12, 2007
We have done some further research (it turned out that I wasn't suffering now the leak so we searched for the differences), and as explained in http://alfonsoml.blogspot.com/2007/12/ie7-leaks-due-to-antiphising-protection.html the problem is only present if the Anti-phising protection of IE7 isn't disabled. That also explains why the problem isn't visible in Drip or sIEve.Anonymous
March 07, 2008
Over the past year, I’ve written about different tools to help web developers become more productiveAnonymous
March 07, 2008
Over the past year, I’ve written about different tools to help web developers become more productiveAnonymous
March 11, 2008
Today I was busy with ASP.NET and Ajax and I had some memory leaks in Internet Explorer 6. So I usedAnonymous
March 19, 2009
    지난  1 년간, Internet Explorer 개발시에 웹 개발자의 생산성 향상을 도모하기 위한 다양한 도구 ( Web Development Tools