Memory leaks that occurs in IE9 when using ng-view

[dharmax]

The following gist demonstrate the problem and also the makeshift solution:
https://gist.github.com/anonymous/6181994

Angular version: 1.1.5

[caguillen214]

@dharmax, Could you try to reproduce this using the newest stable version of Angular?

Thanks

[caguillen214]

Plunker for issue using Angular 1.1.5 and ngBindHtmlUnsafe: http://plnkr.co/edit/ukVJXoYip1IeBskHMmv4?p=preview

[caguillen214]

After some investigation into the topic we were able to find out what factors seen in the issue actually contribute or have no effect to the possible memory leak.

• Contributing factors:
  • The use of ng-view
  • IE only (tested from IE 9 to IE 11)
  • The use of ng-repeat***

***Ng-repeat has yet to be fully tested to see if it contributes to the memory leak. We will replace ng-repeat with a larger DOM element to see if the problem persists

The solution presented by @dharmax in which $templateCache.removeAll() and manually deleting the contents of $scope.arr, by using delete $scope.arr[i] does in fact seem to prevent the memory leak.

[IgorMinar]

When ngView uses template cache, but the cache should only store string
representation of the template so I'm unsure how that would leak.

Let's try to reproduce this without ngView.
On Jul 9, 2014 4:10 PM, "Carlos Guillen" [email protected] wrote:

After some investigation into the topic we were able to find out what
factors seen in the issue actually contribute or have no effect to the
possible memory leak.

Contributing factors:

• The use of ng-view
• IE only (tested from IE 9 to IE 11)
• The use of ng-repeat***

Ng-repeat has yet to be fully tested to see if it contributes to the
memory leak. We will replace ng-repeat with a larger DOM element to see if
the problem persists

The solution presented by @dharmax https://github.com/dharmax in which
$templateCache.removeAll() and manually deleting the array, $scope.arr,
by using `delete $scope.arr[i];is used does in fact seem to prevent the
memory leak.

—
Reply to this email directly or view it on GitHub
#3543 (comment).

[caguillen214]

So after more testing I was able to remove ng-repeat from the factors that contribute to the problem. It seems like the only constant for when the leak occurs is when routing is used. The only time routing doesn't appear to leak is when @dharmax's solution is used.

By using IE 11's memory profiler and snapshot feature, I was able to track the number of objects created and destroyed as well as the heap size between given timespans. Without the solution, the same number of objects were created as were destroyed during changing of views. The heap size also stayed relatively constant; however the total memory used by the page increased as we went through the views.

[IgorMinar]

And what browsers are affected?

On Fri, Jul 11, 2014, 9:32 AM Carlos Guillen [email protected]
wrote:

So after more testing I was able to remove ng-repeat from the factors that
contribute to the problem. It seems like the only constant for when the
leak occurs is when routing is used. The only time routing doesn't appear
to leak is when @dharmax https://github.com/dharmax's solution is used.

—
Reply to this email directly or view it on GitHub
#3543 (comment).

[caguillen214]

It seems to be only firefox and internet explorer that are affected. Firefox and IE have slightly different behaviors thought. Firefox memory usage grows rapidly and then drops to a value higher than its original baseline while IE just continues to grow at a slower rate.

[caguillen214]

@IgorMinar, @jeffbcross and I have tried replacing $templateCache with:

var templateFake = angular.module('templateFake',[]).service('$templateCache',[function() {
  this.get = angular.noop;
  this.put = angular.noop;
}])

Although this prevents $templateCache from storing the template, we still saw a memory leak behavior. The graph below shows changes in memory of the page with increments of 1 route change for a total of 5.

[jeffbcross]

@robpaveza we've been using Developer Tools to analyze memory retained when destroying AngularJS scopes and creating new scopes of similar structure. The heap snapshots tend to be very similar in size, indicating the correct/expected number of scopes in the heap. But the process memory tends to grow pretty quickly (see graph in previous comment). The growth in size correlates to number of scopes and not size of each scope, i.e. if I change the test to produce fewer scopes with each change, the growth is proportionately less, whereas adding huge strings to scopes causes little change to the size of process memory. Apparently, the VM is hanging on to some internal references to the scopes. Can you provide any insight into what could be going on here, and perhaps some way we could work around it?

[caguillen214]

@robpaveza:
Most recent plunker with everything that's not pertinent removed:
http://plnkr.co/edit/3y2wS3COl95iu67Ej2v5?p=preview

[robpaveza]

@jeffbcross I'm looking at the plunker. Can you clarify: by process memory, do you mean what Developer Tools reports as "Total Memory" in its graph, or what something like Task Manager reports as private working set?

I'm not sure where the growth is coming from; in fact, I can't even confirm that you're seeing real growth and not something incorrectly reported with the tool (or the runtime's heap walking APIs).

I'll forward this on to our GC lead as well as folks on the DOM side, since I can't identify where exactly the leak is coming into play.

And @lostintangent (Jonathan Carter), who owns our memory tool.

[IgorMinar]

We see the growth in the Task Manager as well as developer tools.

However if we tried to analyze heap snapshots via the developer tools there
was no growth registered when comparing snapshots (I'm suspecting that
ether the heap profiler is buggy or the leak is invisible to the profiler).
On Jul 22, 2014 5:06 PM, "Rob Paveza" [email protected] wrote:

@jeffbcross https://github.com/jeffbcross I'm looking at the plunker.
Can you clarify: by process memory, do you mean what Developer Tools
reports as "Total Memory" in its graph, or what something like Task Manager
reports as private working set?

I'm not sure where the growth is coming from; in fact, I can't even
confirm that you're seeing real growth and not something incorrectly
reported with the tool (or the runtime's heap walking APIs).

I'll forward this on to our GC lead as well as folks on the DOM side,
since I can't identify where exactly the leak is coming into play.

And @lostintangent https://github.com/lostintangent (Jonathan Carter),
who owns our memory tool.

—
Reply to this email directly or view it on GitHub
#3543 (comment).

[robpaveza]

Memory isn't leaked (at least unbounded) if you don't call the $scope.setItems() function directly within the controller. You can see my recent forks, which include a variation using $timeout and another requiring you to click a button to invoke setItems().

We're still investigating.

[caitp]

@caguillen214 how is this coming? are we blocked on this for beta 18? Is there a PR anywhere?

[jeffbcross]

Hey @robpaveza I don't see any forks of angular.js on your profile. Do you have an inclination as to the cause, and whether it's something that can be solved in Angular?

[jeffbcross]

Oh, you meant plnkr forks. I couldn't find your user (@robpaveza) on plnkr, can you provide links?

[IgorMinar]

Any update on this? Without any information about the cause there is nothing we can do to at least work around the issue.

[tbosch]

Moving to purgatory as we are waiting for more information...