Bug Tracker

Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#6242 closed bug (fixed)

Memory leak in IE8 when using ajax

Reported by: jlhm Owned by: snover
Priority: blocker Milestone: 1.5
Component: ajax Version: 1.4.4
Keywords: IE8 java memory leak Cc:
Blocked by: Blocking:


I've an application where I use the ajax function in jquery to query the web server every second for updated data. In FF the memory utilization remains constant even after running the script for several days. The same thing in IE8 make the memory utilization to increase from around 60 MB to over 1.5GB in less than 24 hours. After some research and testing I've found that nullify event handlers abort and onreadystatechange before nullify xhr in jquery 1.4.2 the memory leak stop in IE8 and the memory utilization remains at the initial allocation +/- 5MB.

Current source:

Stop memory leaks

if ( s.async ) {

xhr = null;


My modified source:

Stop memory leaks

if ( s.async ) {

xhr.onreadystatechange = null; xhr.abort = null; xhr = null;


Change History (28)

comment:1 Changed 7 years ago by Daazku

I also have the same problem on IE7.

But I found a different solution. Just don't use HttpXmlRequest and use activeX for ie. It don't leak anymore.

I also created a ticket before viewed this one.


comment:2 Changed 7 years ago by DNS

I can confirm this on IE7 & IE8 on every machine I've tried it on. I also found a StackOverflow question (http://stackoverflow.com/questions/2429056/simple-jquery-ajax-call-leaks-memory-in-ie) that describes the same problem.

comment:3 Changed 7 years ago by ryleyb

I experienced the same problem and that fix seems to have done the trick.

I haven't detected any downside to doing this yet, ajaxError events still trigger, future AJAX calls seem to still work fine.

comment:5 Changed 7 years ago by domo

I have the same problem in FF3.6.6. The fix seems to works with IE7 (checked with sIEve), but in FF3.6.6 the problem remains.

comment:6 in reply to:  description Changed 7 years ago by pascal

I have the same problem. The fix don't works for me (IE 8). The use of activeX don't resolve the problem too.

I also created a ticket before viewed this one. http://dev.jquery.com/ticket/6802

comment:7 Changed 7 years ago by benjamin

This proposed fix works for me.

I am using long polling to get data from my server app. Users keep my page up all day long. Without this fix, the memory continues to skyrocket. With it, it works as expected.

comment:8 Changed 7 years ago by ta

I'm experiencing the same phenomenon using IE8. I tried to apply the fix, but IE throws an error at me because of xhr.onreadystatechange = null; It's telling me: types incompatible When i output typeof xhr.onreadystatechange the result is 'unknown'. So i'm not really able to confirm if this fixes the problem, since i'm not able to apply it.

Any ideas what the solution might be?

comment:9 Changed 7 years ago by elija

We found that the suggested fix will break IE 6.

Try this instead

Stop memory leaks if ( s.async ) {

if (typeof(xhr) !== 'undefined') {

if (typeof(xhr.onreadystatechange) !== 'unknown' ) {

xhr.onreadystatechange = null;

} if (typeof(xhr.abort) !== 'unknown' ) {

xhr.abort = null;

} xhr = null;



This should also fix the IE7 / 8 issues

comment:10 Changed 7 years ago by snover

Priority: blocker
Status: newopen

comment:11 Changed 7 years ago by chris@…

I can confirm that this is still a bug, as elija and snover have found. With msie6, "onreadystatechange" and "abort" of "xhr" have typeof()s of "unknown", which are shown as "void" types in in the Visual Studio 2010 JavaScript debugger.

comment:12 Changed 7 years ago by jvenema@…

This should work:

try {

x.onreadystatechange = null;

} catch (e3) {

IE6 x.onreadystatechange = function() { };


comment:13 Changed 7 years ago by cobexer

we use this since a few months now and have found no problems so far

// Stop memory leaks
if ( s.async ) {
  try {
    xhr.onreadystatechange = null; xhr.abort = null;
  catch(_) {/* ignore */}
  xhr = null; //this line was there originally

comment:14 Changed 7 years ago by anonymous

I tried this fix (IE8), but for me it's not working. I have an intranet app that gets images from server, and puts them to div tag. First i empty div tag: $("images_div").empty(); Then place new images: $("images_div").html(images);

Memory used by IE8 continues to grow. I tryed Firefox 3.6 and Chrome also, but same problem apears.

Any suggestions?

comment:15 Changed 7 years ago by cobexer

this bug is only related to AJAX requests, your images leak of another reason. There was a problem once with jQuery UI, jQuery UI widgets and empty that caused widgets to not be destroyed when using empty, are your versions up to date?

comment:16 Changed 7 years ago by snover


Retargeting for next release.

comment:17 Changed 7 years ago by anonymous

This didn't fix it for me in IE8.0 I also used a wrapper function on top of editing the jQuery 1.4.3 and still no luck. I am starting to feel that there's something else, more fundamental, with IE8.0 and those annoying memory leaks! Any idea?

comment:18 Changed 7 years ago by anonymous

It worries me that after SO LONG this bug is still present, even though the fix is posted in the forum... what's up guys, this is making systems crash all over... think of all the wasted bytes!!! :)

comment:19 Changed 7 years ago by shayla

I am also seeing this issue, largely in IE8. I haven't yet tested FireFox, but I do not see the same issue in Chrome.

I have applied a suggested change (wrapping .ajax to nullify onreadystatechange and abort), and while the leaks do not appear to grow at such a large rate, the memory used is still increasing (perhaps due to a separate leak, I am not yet certain).

Just want to show another voice that this is quite an issue, and (non-workaround) fix would be greatly appreciated!

comment:20 Changed 6 years ago by snover

Owner: set to snover
Status: openassigned

comment:21 Changed 6 years ago by anonymous

Here's a thread that documents this bug and a possible workaround.


comment:22 Changed 6 years ago by john

Resolution: fixed
Status: assignedclosed


comment:23 Changed 6 years ago by anonymous

I will try the fix but I'm not sure it will fix it as the two function calls will still contain code from noop that occupy some bytes that will not be released by IE. Setting them to null does the release that IE doesn't seems to do. I will let you know how my testing is going.

comment:24 Changed 6 years ago by snover

The leak happened because the attached function references the original object via a closure. This causes a circular reference that IE’s garbage collector does not know how to handle. Dereferencing the function that generated the closure resolves the circular reference and allows GC to occur.

In my testing, after several tens of thousands of XHR calls, memory usage remained flat in IE6-8 with this fix, whereas it increased by several MB/s when the leak was occurring.

The only problem that still exists is that memory leaks in IE7 if a request is aborted; I’m not sure why, but figured that some fixes were better than no fixes. If you can figure out how to stop this, I’m happy to revise the patch.

Last edited 6 years ago by snover (previous) (diff)

comment:25 Changed 6 years ago by anonymous

This neat solution worked for me:

$.ajax($.extend({}, settings, {

complete: function (xhr, status) {

Avoid IE memory leak xhr.onreadystatechange = null; xhr.abort = null;



Based on the suggestion to use a wrapper function here:


comment:26 Changed 6 years ago by jitter


Move fixed tickets to appropriate milestone

comment:27 Changed 6 years ago by saito.yusuke@…

if ( s.async ) {

xhr.onreadystatechange = null; xhr.abort = null; xhr = null;


I have a question...

Why it's only "async"? The memory also leaks in sync ajax, I think. Is it OK to remove "if ( s.async )"??

comment:28 Changed 6 years ago by snover

This code does not exist anymore and this ticket is totally superfluous and irrelevant. Please do not comment any more on it.

comment:29 Changed 6 years ago by zubairuss@…

Hello Sir,

Where should i put that peace of code?

Note: See TracTickets for help on using tickets.