Significant memory leak, possibly caused by ng-repeat

[c0bra]

I've spent the last couple days tracking down a memory leak in a custom directive and decided to try reproducing it with just pure ng-repeat. You can see a demo here (wait the for XHR to load):

http://embed.plnkr.co/v9HVH4/

The plunker swaps between identical routes every 1/4 second, a total of 20 times. You can see the memory in the developer tools timeline grow by about 6MB per route change (from 14MB to ~140MB for me).

Some notes:

1. This happens with automatic and manual route changes.
2. It happens outside plunker, I can reproduce on my local machine by downloading the plunk.
3. The timing doesn't matter. Swapping routes every 2 seconds shows the same results.
4. I cannot reproduce with heap snapshots When I do the 3-snapshot method I don't see any deltas, and the memory stays the same. Could this be related to this bug with Chrome?: https://code.google.com/p/v8/issues/detail?id=2073
5. I have been able to reproduce this in latest Chrome and in Canary.

[pkozlowski-opensource]

This strangely reminds me of #4864 which, as far as I remember, was declared as a bug in dev tools: https://code.google.com/p/chromium/issues/detail?id=304689

See more details here: #4864 (comment)

[dzdrazil]

I don't think it's just a Chrome bug, I'm tearing my hair out with the same issue that I was able to reproduce in IE11.

I've just spent a day and a half debugging the exact same issue- switching between routes has been causing steady creeps in memory usage, up to the point where it crashes chrome, and the biggest pushers of memory have been pages with nested ng-repeat directives. I've reproduced the issue in IE11 as well, and can reproduce in the heap snapshots as well.

I can't demo code yet- too much business specific code- but I'm at the point where I may spend a few hours coming up with a safe to share example. I will say the biggest standout from what I've been able to see has been tons and tons of detached DOM nodes / trees. If someone doesn't beat me to it, I'll edit with a

[dzdrazil]

On second thought, maybe I'm seeing something different- in c0bra's http://embed.plnkr.co/v9HVH4/ example, hitting Collect Garbage on the timeline was bringing DOM Node count down to 6329 each time.

[Narretz]

@dzdrazil if it (reliably) crashes Chrome, have you been able to crash it without the Developer tools open or recording the memory usage?

[c0bra]

@dzdrazil just fyi I tried that on my plunker after I saw your comments. It leaks whether or not the developer tools are open, based on the Chrome task manager.

[dzdrazil]

@Narretz, in my paritcular case, I was able to show in multiple browsers that memory was leaking- it had something to do with objects on a $scope that had arrays, which were then accessed by templates. Detatched DOM trees galore! I was able to resolve it by adding $scope.$on('$destroy'... everywhere, but that's an issue unrelated to this ticket, and I'll file it once I have a minimalist code sample to prove it.

@c0bra, I'm convinced it's not a memory leak so much as it is the loop is creating garbage so quckly and consistently that GC won't kick in in time to save the session.

Try this- click on single swap once a second. In my experience, memory use grew to and capped out at 125mb (looking at js memory in the chrome task manager). Even with clicking it quickly, then pausing a bit, then clicking some more, then pausing a bit, the most I could get it up to was 200mb before (slowing down the clicking and extending the pauses) it eventually settled back at the 60-70mb baseline.

[RossJayJones]

I'm seeing the same behavior. Can't prove it yet but working on a sample. Looks like things are being held there by a variable named "clone". But I could just be mis-reading the dev tools output.

[btesser]

I'm seeing the same behavior as well. As soon as I removed the ng-repeat, the leaks were gone. The plnkr very clearly shows this. Any chance on getting a fix for this?