Memory Leak in IE9 with AngularJS 1.2.28

[m-unterberger]

The following gist demonstrate the problem. It is a very basic example that switches between two views. With IE9 (Version 9.0.15) on Windows 7 the memory consumption for process "iexplore" continues to grow until it crashes.

https://gist.github.com/m-unterberger/e90ec1552df6b43bafc9

[petebacondarwin]

It does indeed seem that there is a leak here.

[petebacondarwin]

Does it do this with other 1.2.x versions? What about 1.3?

[vitaly-t]

+1 could we really please determine the range of Angular versions where the issue exists? It is seemingly important.

[petebacondarwin]

It seems to occur on all versions from 1.2.x and 1.3.x
See alternate version https://gist.github.com/petebacondarwin/114540d31daf115694f7

[vitaly-t]

I should have asked before - is it really IE9 - specific? It is unclear from above posts whether the issue was excluded from other browsers.

[petebacondarwin]

I only saw it on IE9 but haven't tested other IEs

[m-unterberger]

We testet it with IE 11 and other browsers (Chrome, Firefox, Safari) in the actual version. The problem was observed only with IE 9

[Tim91084]

@petebacondarwin

The following code seems to mitigate the memory issue in IE9 (for the most part). Seems like as long as you explicitly call destroy on all child scopes, IE9 is able to clean up. Not sure why that is...

In general, I've found this leak to not only be a problem with ngRoute/ngView, but any component which creates and then destroys DOM elements (ngIf, ngSwitch, ngInclude).

I also only observe this issue in IE9. I wouldn't mind a heads up if you guys see something terribly wrong with the code below :)

Adding a reference to other, similar issues: #3543, #1216, #2624

(function () {
'use strict'
angular
    .module('ng')
    .config(["$provide", function ($provide) {
        $provide.decorator("$rootScope", rootScopeDecorator)
    }]);

rootScopeDecorator.$inject = ["$delegate"];
function rootScopeDecorator($delegate) {
    var original_destroy = $delegate.$destroy;
    var original_new = $delegate.$new;

    $delegate.$destroy = ie9_destroy;
    $delegate.$new = ie9_new;
    return $delegate;

    function ie9_new() {
        var scope = original_new.apply(this, arguments);
        scope.$destroy = ie9_destroy;
        scope.$new = ie9_new;
        return scope;
    }

    function ie9_destroy() {
        //only destroy children of the first.  recurse to the bottom and destroy all scopes
        if (this.$$childHead) {
            this.$$childHead.$destroy(true);
        }

        if (arguments[0] && this.$$nextSibling) {
            this.$$nextSibling.$destroy(true);
        }

        original_destroy.call(this);
    }
}
})();

[wesleycho]

That would be a breaking change, since $destroy broadcasts the $destroy event to child scopes, which would broadcast a new event each time.

[Tim91084]

@wesleycho
Not quite sure what you mean.. Still only 1 $destroy event is triggered per scope (I think). This recursively iterates to the lowest scope in the hierarchy, calls $destroy there and works it's way back up. Since all children of a scope would be destroyed before that scope is destroyed, I don't think the broadcast would hit the already destroyed scopes, again, when destroying the parents - if that makes any sense...

Is your concern that the $destroy event would be triggered multiple times for the same scope?

[petebacondarwin]

I can confirm that this decorator does indeed stop the leak. So the question is, why do we need to explicitly recurse and call $destroy when the broadcast should be enough...

[petebacondarwin]

I can also confirm that it is happening on master (i.e. 1.4.0-rc.1) for IE9

[petebacondarwin]

OK, so $scope.$broadcast('$destroy'); actually does nothing for internally deallocation except ensure that isolated scopes that do not prototypically inherit the $destroyed property have this property set.

I believe that the point of the $destroy event is to allow application developers to hook into the destruction of the scope and de-allocate their own resources as necessary.

[petebacondarwin]

In fact this is enough to remove the memory leak:

function rootScopeDecorator($delegate) {
    var original_destroy = $delegate.$destroy;
    var original_new = $delegate.$new;

    $delegate.$destroy = ie9_destroy;
    $delegate.$new = ie9_new;
    return $delegate;

    function ie9_new() {
        var scope = original_new.apply(this, arguments);
        scope.$destroy = ie9_destroy;
        scope.$new = ie9_new;
        return scope;
    }

    function ie9_destroy(fake) {
        //only destroy children of the first.  recurse to the bottom and destroy all scopes
        if (this.$$childHead) {
            this.$$childHead.$destroy(true);
        }

        if (arguments[0] && this.$$nextSibling) {
            this.$$nextSibling.$destroy(true);
        }

        if (!fake) original_destroy.call(this);

        this.$parent = this.$$nextSibling = this.$$prevSibling = this.$$childHead =
            this.$$childTail = this.$root = this.$$watchers = null;
    }
}

Not that we only call the original $destroy on the top level scope but we clean out the properties of all the scopes from the bottom up.

[saravana1182]

Is this fixed in IE 11? I am seeing all of my watchers are remains in memory and leaking. The code fix is msie===9 and won't work for higher version.