Skip to main content

Simple jQuery Ajax call leaks memory in Internet Explorer


I created a web page that makes an Ajax call every second. In Internet Explorer 7, it leaks memory badly (20 MB in about 15 minutes).



The program is very simple. It just runs a JavaScript function that makes an Ajax call. The server returns an empty string, and the JavaScript code does nothing with it. I use setTimeout to run the function every second, and I'm using Drip to watch the thing.



Here is the source:




<html>
<head>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load('jquery', '1.4.2');
google.load('jqueryui', '1.7.2');
</script>
<script type="text/javascript">
setTimeout('testJunk()',1000);
function testJunk() {
$.ajax({ url: 'http://xxxxxxxxxxxxxx/test', // The url returns an empty string
dataType: 'html',
success: function(data){}
});
setTimeout('testJunk()',1000)
}
</script>
</head>
<body>
Why is memory usage going up?
</body>
</html>



How to plug this leak? I have a real application that updates a large table this way, but left unattended it will eat up gigabytes of memory.



Edit : okay, so after some good suggestions, I modified the code to:




<html>
<head>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load('jquery', '1.4.2');
google.load('jqueryui', '1.7.2');
</script>
<script type="text/javascript">
setTimeout(testJunk,1000);
function testJunk() {
$.ajax({ url: 'http://xxxxxxxxxxxxxx/test', // The url returns an empty string
dataType: 'html',
success: function(data){setTimeout(testJunk,1000)}
});
}
</script>
</head>
<body>
Why is memory usage going up?
</body>
</html>



It didn't seem to make any difference, though. I'm not doing anything with the DOM, and if I comment out the Ajax call, the memory leak stops. So it looks like the leak is entirely in the Ajax call. Does jQuery Ajax inherently create some sort of circular reference, and if so, how can I free it? By the way, it doesn't leak in Firefox.



Someone suggested running the test in another VM and see if the results are the same. Rather than setting up another VM, I found a laptop that was running XP Home with Internet Explorer 8. It exhibits the same problem.



I tried some older versions of jQuery and got better results, but the problem didn't go away entirely until I abandoned Ajax in jQuery and went with more traditional (and ugly) Ajax.


Source: Tips4allCCNA FINAL EXAM

Comments

  1. Here's a link to the bug over on jQuery, along with this as a suggested fix for jQuery 1.4.2:

    --- jquery-1.4.2.js 2010-04-08 12:10:20.000000000 -0700
    +++ jquery-1.4.2.js.fixed 2010-04-08 12:10:38.000000000 -0700
    @@ -5219,7 +5219,7 @@

    // Stop memory leaks
    if ( s.async ) {
    - xhr = null;
    + xhr.onreadystatechange = null; xhr.abort = null; xhr = null;
    }
    }
    };


    NOTE: This is officially fixed in jQuery 1.4.4, so your best bet is to just upgrade now.

    ReplyDelete
  2. The problem appears to be with jQuery 1.4 in Internet Explorer, and to a lesser extent, versions 1.2 and 1.3.

    1.4.0, 1.4.1, and 1.4.2 all exhibited the severe memory leak.

    1.2.3, 1.2.6, 1.3.0, 1.3.1, and 1.3.2 all exhibited a much smaller leak (about 100 KB after 10 minutes).

    I also tried a version of my program that calls Ajax in a more traditional way:

    <html>
    <head>
    <script language="javascript" type="text/javascript">
    function getHTTPObject() {
    var xmlhttp;
    /*@cc_on
    @if (@_jscript_version >= 5)
    try {
    xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (E) {
    xmlhttp = false;
    }
    }
    @else
    xmlhttp = false;
    @end @*/
    if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
    try {
    xmlhttp = new XMLHttpRequest();
    if (xmlhttp.overrideMimeType) {
    xmlhttp.overrideMimeType("text/xml");
    }
    } catch (e) {
    xmlhttp = false;
    }
    }
    return xmlhttp;
    }
    var ajaxObject = getHTTPObject();
    setTimeout(testJunk,1000);
    function testJunk() {
    ajaxObject.open('POST', 'http://XXXXXXXXXXXXXXX/delme2', true);
    ajaxObject.onreadystatechange = handleAjaxResponse;
    ajaxObject.send(null);
    }
    function handleAjaxResponse() {
    if (ajaxObject.readyState==4) {
    setTimeout(testJunk,1000);
    }
    }
    </script>
    </head>
    <body>
    <div id="test">Why is memory usage going up?</div>
    </body>
    </html>


    This got rid of the leak entirely.

    So it looks like I'll have to do my repeating Ajax calls the ugly old way until the jQuery folks iron out this problem.

    ReplyDelete
  3. eval() will eat up memory for sure (eval happens when passing a string to setTimeout to evaluate), don't use it in testing:

    setTimeout('testJunk()',1000);


    should be:

    setTimeout(testJunk, 1000);


    Also a better use overall would be setInterval() for a repeated operation like you want, try this:

    setInterval(testJunk, 1000);

    ReplyDelete
  4. I encountered the same issue and had been stumped all morning ... until a few moments ago. The problem is a circular reference that is created when you set the onreadystatechange handler, that IE isn't smart enough to break. The solution, therefore, is to break it explicitly. However, obviously you can't do it from within the handler itself (though it would be convenient if you could!).

    The magic statement:

    delete request['onreadystatechange'];


    You need to keep a record of each XMLHttpRequest object for which you set onreadystatechange. Then, at some point after readyState goes to 4, do your magic on the object. If you are already performing a repeated AJAX poll, the logical place to check for requests to clean up would be in the same polling loop. I defined a simple RequestTracker object to manage my requests.

    This worked for me; I verified that it solved the leak. Here's one link in particular that led the way (I would post more, but StackOverflow isn't letting me):


    http://bytes.com/topic/javascript/answers/152714-closures-xmlhttprequest-memory-leak

    ReplyDelete
  5. One problem with your code is that if your ajax request start to take a while you will start flooding the browser and server with ajax request you really should wait till the browser gets a return from the server before kicking off the next one.

    function testJunk() {
    $.ajax({ url: 'http://xxxxxxxxxxxxxx/test', // The url returns an empty string
    dataType: 'html',
    complete: function(data){
    setTimeout(testJunk,1000);
    }
    });
    }
    testJunk();

    ReplyDelete
  6. Just encountered this myself. I thought it was something to do with the UI library initially, but then it disappeared after I swapped in jQuery 1.5. for the version 1.4.2 that I was using. (1.4.4 didn't seem to fix the issue).

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex