Wednesday, June 1st, 2005

Drip: IE Leak Detector

Category: Browsers, IE, JavaScript, Utility

One of the major issues in developing JavaScript applications (and hence Ajax) is that over time we have found memory leaks in implementations such as in IE (JScript).

Joel Webber has stepped up to the plate and has released an early version of a leak detector for IE:

It’s a pretty simple application. Basically, it lets you open an HTML page (or pages, in succession) in a dialog box, mess around with it, then check for any elements that were leaked.

Blowing Memory

Back to the main dialog for a moment. You might also have noticed the interestingly-titled ‘blow memory’ button. Its function is simple: to constantly reload a page as fast as it can, and to report the process’ memory usage in the list box below. This is a helluva lot easier than pressing F5 for hours to determine how fast a page leaks memory.

How it works

Fortunately, Internet Explorer’s architecture made this app fairly easy to build. It’s basically a simple MFC app with a browser COM component in it. The strategy for catching leaked elements is as follows:

  • Can you perform similar tricks with Safari/KHTML or Opera? (I know you can with Mozilla, but since it doesn’t really leak much, that seems rather pointless)
  • Does anyone know if it’s possible to enumerate variables on one of IE’s JavaScript closures? (meaning the stack frame hanging off of the function reference)
  • How about enumerating expandos on IE DOM objects from C++? (I only seem to get built-in properties from ITypeInfo)

Download Drip

Read more about Drip

Posted by Dion Almaer at 11:27 am

3.7 rating from 11 votes


Comments feed

I had high expectations, but the program is very limited. I was unable to test a complex interface because it depends on reloading entire windows.

Comment by M. Schopman — June 1, 2005

I have to say this is a useful tool. Good find! There is definately room for growth but perhaps this will inspire IDE makers to build similar tools?

Comment by alexeiwhite — June 1, 2005

M. Schopman: I would very much like to make this utility more useful, particularly for AJAX-style applications in which you don’t reload the entire window often. Currently, however, there is no way to avoid this, as it’s about the only way to get IE to drop its references to COM objects so that you can figure out which ones were leaked.

If you could give me an idea of the kind of application you’re trying to test, however, perhaps we could find a way to extend Drip such that you can at least catch the leaks, even though it may be slightly inconvenient?

Thanks for the feedback!

Comment by Joel Webber — June 1, 2005

I don’t know if it’s still there, but a while ago the guys at the DomAPI had released an ActiveX dll that measured various aspects of memory usage on a single process…I used it to write a graphing real-time Memory profiler (graphing in SVG) that I used pretty successfully to diagnose mem leaks in IE. It’s pretty old (I wrote it in 2002, and the dll had been around a little longer than that), but it still works very well. Basically I wrote it as a bookmarklet served from the local machine…

If anyone is interested (it is IE/Win only), drop me a line and I’ll see about talking to the DomAPI guys about it.

Comment by Tom Trenka — June 1, 2005

Hi Tom Trenka,

I’d be interested to use your ActiveX dll — our AJAX app is I.E only — would be useful to try it on that.


Comment by Anjan Bacchu — June 2, 2005

After re-reading, my comment wasn’t really subtle. I like the idea, the concept, the effort and the first steps taken. It would be nice if the application could somehow support a way to detect leaks within a combined document (+frames/+iframes). That would be really helpfull.

Comment by M. Schopman — June 2, 2005

I’ve also had a couple of people mention frame issues (here and elsewhere). I’ve tested simple cases involving framesets and iframes, with no problems (this is why the leak dialog shows the URL of each leaked element — so you can tell which frame leaked it).

I’m sure I’ve missed some cases, so if anyone could point me to an example or use case that is problematic, I would greatly appreciate it!

Comment by Joel Webber — June 2, 2005

OK. Here’s the link to the DLL in question:

You can definitely start with that; all I did was put a nice interface over it. One nice thing about it is that it attaches to the process that launched it and that’s all, so you get a MUCH more accurate picture of memory usage than a pure JS one.

If there’s still interest in the GUI I put together for it, drop me an email and I’ll post it somewhere (there’s some address stuff you need to do to make it work, and I wrote it to run from localhost only, so if there’s other needs I’ll try to address them).

Comment by Tom Trenka — June 3, 2005

I find the Drip utility pretty useful, but it only keeps track of the html elements that are created when the page first loads or that are dynamically added to the page using document.createElement(). In our app we load the page only once and then constantly add new html elements by setting innerHTML of the various divs. But the Drip doesn’t register those html elements in it’s JSHook. Can this be fixed? I downloaded the C++ code, but I have no idea how to overwrite the browser’s innerHTML = xxx thing (in a similar way it overwrites the createElement). Please help!!

Comment by Marina — July 6, 2005

Is there any information (that’s still online, unlike Joel Webber’s blog) telling how to use this tool? I am profiling a web app and there are leaked objects, but could somebody kindly explain what the “DOM Element Leaks” means?

Comment by Jeremy Wiebe — November 8, 2005

this tools seems to have moved to this URL:


Comment by DhtmlGuy — July 15, 2010

Leave a comment

You must be logged in to post a comment.