nested ng-repeat causes memory leak

[jweir]

This has been confirmed in Chrome 21.0.1180.82

http://jsfiddle.net/LEWmd/54/

Using an ng-repeat within an ng-repeat cause a memory leak and eventually the window will crash.

[polidore]

Same issue in 23.0.1271.10 dev-m with angular 1.1 and 1.0.2.

[iatemykindle]

Not sure if it's the same bug, but it appears that in chrome whenever you have a controller inside an ng-repeat, the memory also blows up (in chrome)

[alex-sitnikov]

Guys, any workaround on this issue?

[iatemykindle]

I created a custom directive that does the ng-repeat manually. It seems to work fine.

[alex-sitnikov]

Can you share you solution with us?

[iatemykindle]

Oh, sure. It's nothing fancy, you can check out this js-fiddle: http://jsfiddle.net/namit101/g2jZ4/

Based on AngularJS v1.0.1:

V8 have about classic ref-counted GC.

AngularJS Scope constructor:

    function Scope() {
      this.$id = nextUid();
      this.$$phase = this.$parent = this.$$watchers =
                     this.$$nextSibling = this.$$prevSibling =
                     this.$$childHead = this.$$childTail = null;
      this['this'] = this.$root =  this;
      this.$$asyncQueue = [];
      this.$$listeners = {};
    }

There is destroy method which in original sample doesn't cleanup object completely:

      $destroy: function() {
        if ($rootScope == this) return; // we can't remove the root node;
        var parent = this.$parent;

        this.$broadcast('$destroy');

        if (parent.$$childHead == this) parent.$$childHead = this.$$nextSibling;
        if (parent.$$childTail == this) parent.$$childTail = this.$$prevSibling;
        if (this.$$prevSibling) this.$$prevSibling.$$nextSibling = this.$$nextSibling;
        if (this.$$nextSibling) this.$$nextSibling.$$prevSibling = this.$$prevSibling;

      //------- my additions -----------------------
      this.$id = null;
      this.$$phase = this.$parent = this.$$watchers =
                     this.$$nextSibling = this.$$prevSibling =
                     this.$$childHead = this.$$childTail = null;
      this['this'] = this.$root =  null;
      this.$$asyncQueue = null; // fixme: how this must be properly cleaned?
      this.$$listeners = null; // fixme: how this must be properly cleaned?

      },

This solves memory leak for jweir's sample ( http://jsfiddle.net/LEWmd/54/ ) for me.

[davidhoyt]

+1 fddima's solution has solved the problem for me.

Just note, that my solution can break something else.

[davidhoyt]

I have a rather simple app and your solution hasn't broken anything in my case. I'm still learning angular and so I cannot say what side effects it may have elsewhere.

What my app does is periodically poll the server on a timer for the latest information and then re-renders (re-applies) when that data comes in. I was seeing the number of nodes in the dom go up and up and up without ever coming down.

Applying your fix alleviated the situation and the app behaves as expected.

[IgorMinar]

This is a bug in the garbage collector of Chrome.

Try running the fiddle in Safari or Firefox and you'll see that there is no memleak there.

Also try to remove setInterval and replace it with manually triggered regeneration of the model and you'll see that there is no leak: http://jsfiddle.net/LEWmd/122/

(just take heap snapshot and look up how many references of Date object are being retained by angular, the number is always 2 no matter how many times you click the button (regenerate the model))

The difference between setInterval and manually triggering the action is that setTimeout runs often enough to cause Chrome's optimizer to kick in which causes some of the code and references to be cached in internal caches (outside of the reach of regular js code).

Funny enough (or in fact sadly) @fddima's suggestions works. It's enough to add

this.$$nextSibling = null;

to Scope's $destroy method and all is good, even though this change doesn't make the scope object any less reachable from the GC root. the $destroy implementation correctly severs all references to the scope object being destroyed and if the GC in Chrome was working properly it wouldn't be necessary to reset and references from this object.

That said, I'm going to reset all references to other scopes from the scope that is being destroyed to please chrome. I'm also going to escalate the issue with the chrome team (they are already aware of this, we've seen similar issues in other circumstances).

The related Chrome bug is here: https://code.google.com/p/v8/issues/detail?id=2073