IE8 memory leak that persists after page refresh

[Pete Jones]

Hi all,

We've got a complicated, enterprise-y app that we recently re-wrote in angular, and we're experiencing crippling memory leaks in IE8 that persist after page refreshes.  The memory leaks fast, and is never reclaimed - not until IE is closed (or crashes - yikes!).  We have not experienced memory issues in other browsers (we don't support IE<8).

• We're using angular 1.1.5, but are testing 1.2 as well, which seems to improve performance slightly, but it does not cure the IE8 memory leak
• We haven't been able to isolate the leak.  In turning components on and off, we have generally seen that all components have some memory leaking effect - the more that's turned off, the smaller the leak. No smoking guns. 
• We don't reference DOM elements in directive scope's, and we don't reference DOM outside directives.  (We do really need to comb our libraries for bad behavior (select2, angular-ui, etc), though).
• Almost everything in our app is part of an ng-repeat (which is likely nested under another ng-repeat or two - it's a complex app).
• We do use $watch() and $timeout in several places, but have tried to minimize their usage.
• We use full-blown jQuery 1.7.2 (I can't remember why we aren't up to 1.9) 
• The symptoms are just like an older IE bug that doesn't affect IE8.
  
• We have tried explicitly nullifying JS objects and removing DOM elements to make sure they are flagged for garbage collection.  For instance, before unloading the page, we've tried tearing down the angular app (with this and other methods), setting models to null, and calling $('body').remove().  We've also tried performing these manual cleanings during other UI updates/interactions.  
• We've noticed several other sites that use angular cause IE8 to leak memory, but they all have used angular < 1.0.

Do you have any ideas for possible causes?  Patterns that are known to trigger IE8 memory leaks?  Any live apps that exhibit the same symptoms? 

We are still working to isolate a simple test case - I'll certainly update if and when we manage it.

Thanks!

Pete

[Pete Jones]

We've had some success after updating jQuery from 1.7.2 to 1.10.2.  It appears that most of the memory allocated during a given page's lifecycle now get's released when you go to the next page.  Might be helping because of this jQuery < 1.8 bug?

We still get a torrential memory leak during a given pageview - that isn't released even when the browser is out of memory (it crashes!), unless the page is unloaded.  Smells a little like this IE8 element bug but the IE settings change workaround suggested here doesn't work...

Still looking for ideas!

[Cary Landholt]

You're experiencing a cross-page leak.

http://msdn.microsoft.com/en-us/library/bb250448(v=vs.85).aspx

I've battled those in the past.  As with most leaks, they are often difficult to find.  The good news is almost all cross-page leaks can be addressed.

IE8 is, however, a very leaky browser.

Any chance you can share your code?

[Pete Jones]

Ah, a fellow veteran of the IE wars!

Unfortunately, we can't share the complete code - proprietary blah blah blah and all that - and we have still not isolated a manageable subset of it that exhibits the memory leak. Probably a sign we have some code bloat!

Do you know which (if any) of those issues apply to IE8?  (That article is dated before IE8 was released, and I can't seem to find a definitive or authoritative list that applies to IE8...)  

Thanks!

Pete

[Landholt, Cary]

Unfortunately, no.  Sorry.

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/OL0q0EsNCuI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.

[Jan Prinsloo]

Hi Pete

Sounds like we've got the same setup and problems as you.

The problem was discovered recently so haven't tried everything you have - only the jQuery update to 1.10.2 with no effect.

Have you tried clearing the $templateCache as described in the following thread? https://groups.google.com/forum/#!topic/angular/ZfSFG9EOgGA. 

We're using ui-router with 200+ html files converted using grunt-html2js, so this is the next thing I'm going to try.

Have you had any success yet?

Thanks

Jan

[Peter Jones]

Hi Jan,

Sorry to hear you are in the same boat!  

I saw that thread, but concluded it wasn't directly applicable because Igor's fix was related to having one app nested in another (https://github.com/angular/angular.js/commit/6c663154943e4c0c33c19026a7b500302bda29d4).  

That said, we tried all sorts of similar things before the page unloads: 

We have tried explicitly nullifying JS objects and removing DOM elements to make sure they are flagged for garbage collection.  For instance, before unloading the page, we've tried tearing down the angular app (with this and other methods), setting models to null, and calling $('body').remove().  We've also tried performing these manual cleanings during other UI updates/interactions.  

Basically, trying to restore the page to an empty state before leaving it.  Some things seemed to help a little, but nothing really measurable.  Upgrading jQuery was a huge help, though we do still observe a slow, steady leak, especially on XP.  

We had also upgraded to angular 1.2, and noticed a significant improvement, but we had some breaks and rolled it back, not having time to fix them at the time.  We are planning on upgrading soon, though.  

We are currently cruising the most heavily trodden code for $watches we can tear out and replacing slow UI widgets (select2, I'm looking at you).

[Jan Prinsloo]

Hi Peter

Thanks for your reply. Yeah - clearing of template cache hasn't helped. 

Had to move on to other things, but I did a quick test to see what effect removing some of our own directives had which seemed to make the leak less pronounced. Doing some transclusion in these directives, so going to investigate that further.

I've seen a couple of threads which say when you use $compile, you should create a child scope and destroy it explicitly - see http://roubenmeschian.com/rubo/?p=51. The same thing is done in ngView and uiView directives...

Will also try the 1.2 upgrade and keep updating here if I can find anything useful.

Good luck - I hope we can solve this thing!

[referee work]

I cover those issues with IE8

For the latest information on a workaround?

[Jan Prinsloo]

In our case the problem was an html5.js file included with another framework we were using - https://remysharp.com/2009/01/07/html5-enabling-script

After removing it all our problems were gone. Hope this helps - good luck!

On Tue, Sep 15, 2015 at 12:56 PM referee work <refere...@gmail.com> wrote:

I cover those issues with IE8

For the latest information on a workaround?

--

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/OL0q0EsNCuI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.

For more options, visit https://groups.google.com/d/optout.

[Roman Nevostruev]

Removal html5shiv.js did not help :(

вторник, 15 сентября 2015 г., 17:37:30 UTC+5 пользователь Jan Prinsloo написал: