ngRepeat "track by" possible memory leak

[bensgroi]

I'm submitting a ...

• bug report
• feature request
• other

Current behavior:

Adding a track by to an ngRepeat causes a memory leak, so that the component's controller is retained in memory.

Expected / new behavior:

Using track by on an ngRepeat should not cause any side effects.

Minimal reproduction of the problem with instructions:

Plunker
To see the memory leak in action, you'll need to run the demo in its own tab: https://run.plnkr.co/plunks/pToAURpUzO2pdOq6H0Yf/

It contains two child components, a "leaky" version and a "non-leaky" version, the only difference between them being the addition of a "track by" on the leaky one.

1. Click on "Leaky Component", then "Non-Leaky Component", then "Reset"
2. Take a heap snapshot. Filter on "leaky". You'll see that the "leaky" component is still in memory, though not reachable. The "non-leaky" component has been GC'ed and is no longer on the heap.
   

The presence of "track by" seems to cause a leak. Using track by $index has the same effect. This seems like a really obvious bug, but I haven't been able to find anything related to it here yet. Am I missing something?

AngularJS version: 1.7.5

Also reproduced in 1.5.8

Browser: Chrome 70

[gkalpak]

Thx for reporting this. Have you manually triggered GC before taking the heap snapshot? If the element is not reachable (as you said), then it would be a GC bug not to get rid of it.

[bensgroi]

@gkalpak Taking a heap snapshot automatically runs GC beforehand.

[bensgroi]

I updated the Plunker and repro steps to make it a bit clearer.

[petebacondarwin]

I might not be reading this right but as far as I can tell only one instance is ever created, even if you toggle the ng-if many times. I appreciate that this doesn't mean there is no memory leak but it does give us some more information for debugging this...

[bensgroi]

@petebacondarwin True, the scope of the leak is limited. But if the controller were to have enough data in it and/or have $scope injected (which could lead to the whole scope tree leaking), the impact could be noticeable on memory usage.

[jbedard]

Good catch @bensgroi! Turns out there's actually 2 problems:

1. The trackByIdExpFn references the scope (link level) but is cached at the compilation level, so the scope leaks like you pointed out. It will get cleaned along with the compilation data, but that is a little too late.
2. The trackByIdExpFn is only created on the very first link of an ng-repeat, so if the repeat is repeated, all but the first will have the wrong $scope.

[jbedard]

For reference, another issue we found which will also be fixed:

3. If track by is used then the last value from the collection is leaked to the compilation level, so if the element+scope gets removed the value is still referenced. Basically the same as the first issue but with only the last value leaked and not the full scope.