IE: stack overflow at line: 0

Today, I noticed the following issue (IE only, of course). Running a page that does some comet (via “XHR GET” for long-polling), I got the following warning: “stack overflow at line: 0”  and the application stopped working…

I did some google-searches and found some “hints” that said I should disable my third-party tools for IE etc. That sounds strange…

In fact the problem was the odd cache behavior of the IE. The XML (from the “long-polling servlet”) was cached and its JS was executed; also the application itself started the polling too, so I (no IE) ran into this odd issue…

Changing the server-side code – that is responsible to render the XML – to have no cache rules (e.g.”Cache-Control”:”no-cache”) did the trick. It worked again. Of course, on your “comet output” you potentially don’t want cache to be present…

So fixing the cache solved the issue. There was no need to disable Norton or any other third-party tool…🙂

Howdy!

Posted in ajax, comet, javascript, web²
4 comments on “IE: stack overflow at line: 0
  1. ggggggggggggggggggggggggggggggggggggggggggggg🙂.

    IE really sucks🙂.

  2. ryan says:

    you wrote: Changing the server-side code did the trick.

    How do I do that?

    where do I enter no-cache?

  3. Andy Castles says:

    We had a similar issue where we were using an Ajax call to download a static .js file and execute it. IE6 gave a “stack overflow at line: 0”.

    In the end we disabled caching by appending a random number on the end of the .js path and it solved the problem (i.e. code.js?rnd=283764).

    Very annoying and causes us to not be able to cache the .js file even though it’s a static file… 😦

  4. Andy Castles says:

    Just to follow-up on my previous comment, in the end we avoided disabling the cache hack described above by wrapping the Ajax call in a setTimeout command:
    setTimeout(function(){
    (new Ajax.Request(“code.js”, {
    method: ‘get’,
    onComplete: function() {
    // code here
    },
    }))
    },0);

    This seems to have the effect of creating a “new thread”, and presumably the stack is reset so the overflow message doesn’t appear and the file can continue to be cached.

    In testing, we only had the problem in IE6 and IE7, IE8 seemed to be okay, but the setTimeout fix works for all 3 versions.

    (We are using Prototype as our JS framework.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: