ajax ie8内存泄漏,#6242 (Memory leak in IE8 when using ajax) – jQuery - Bug Tracker
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.
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.
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.
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.
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
11年 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.
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?
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
优先级:
→ blocker
状态:
new →
open
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.
11年 ago by jvenema@…
This should work:
try {
x.onreadystatechange = null;
} catch (e3) {
IE6
x.onreadystatechange = function() { };
}
11年 ago by Christoph Obexer
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
}
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?
11年 ago by Christoph Obexer
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?
里程碑:
1.4.3 →
1.4.5
Retargeting for next release.
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?
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!!! :)
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!
属主:
设置为 snover
状态:
open →
assigned
处理结果:
→ fixed
版本:
1.4.2 →
1.4.4
状态:
assigned →
closed
Landed.
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.
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 11年 ago
by snover
(上一个)
(差异)
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:
里程碑:
1.4.5 →
1.5
Move fixed tickets to appropriate milestone
11年 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 )"??
This code does not exist anymore and this ticket is totally superfluous and irrelevant. Please do not comment any more on it.
10年 ago by zubairuss@…
Hello Sir,
Where should i put that peace of code?