Ember.js: Memory on acceptance tests on ember 1.13.10+

[calderas]

test repo: https://github.com/calderas/leaky-mcleakerson

After upgrading our app to ember 1.13 chrome crashes when running Acceptance Tests

V8 error: Allocation failed - process out of memory (CALL_AND_RETRY_LAST).  Current memory usage: 1949 MB

Following the same approach as https://github.com/emberjs/ember.js/issues/11748 I ran some tests on a simple app to compare different versions of ember

Observations:

• Memory drops when running unit tests on ember 1.12.
• Memory allocated for tests is ~ twice on ember 1.13 & 2.1 for same app.

• Memory allocation tends to increase overtime on acceptance tests.

  Questions:

• Is this expected ?

• Thoughts on how to debug further ?
  

  Memory comparison

Looking at the timeline seems like event listeners remain after tests have completed and detached elements show up on heap profiles.

test repo: https://github.com/calderas/leaky-mcleakerson

[jcope2013]

this one seems related also https://github.com/emberjs/ember.js/issues/12490 and I have been having similar issues with my app

[lmcardle]

I've also been struggling with this on 1.13.10. No idea if this would be helpful, but here is my timeline and heap profile.

[stefanpenner]

@lmcardle it is unfortunately not at all helpful, the only thing that is valuable is actual examples demonstrating leaks.

[stefanpenner]

Thoughts on how to debug further ?

yes, heap snapshot, find the retainers and address them.

[stefanpenner]

I took a look, although there may be more leaks. I believe I found a v8 bug. It appears to be leaking due to an inlined function preserving its context...

After some digging, I found:

Which seems to indicate the normalize function (which doesn't close over anything) via its compiled code and related deopt info, is retaining the resolver.

The following stack appears inlined (causing the grief).

1. resolve.normalize
2. this.registry.normalizeFullName = this.applicationRegistry.normalizeFullName;
   
3. Registry.prototypr.normalize

I then pinged @mraleph on twitter, who recommended i disabling inlining and try again.

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --js-flags="--nouse_inlining" --user-data-dir=/tmp/foobar

Manually preventing this specific set of functions from inlining also prevents the leak. hacky patch

And the container leak I noticed went away...

cc @dgeb

• [x] open v8 issue https://code.google.com/p/v8/issues/detail?id=4578&thanks=4578&ts=1448559714
• [x] more reasonable work-around? The spot fixes feel terribad... as they only scenario solve the issue hacky patch
  basically move away from shadowing methods on instances, rather using subclassing

[stefanpenner]

FYI: when searching for memory leaks, having examples that create excessive noise only creates distractions and make finding the source of the leak more difficult.

The key is finding the minimal setup required to cause a leak, basically deleting parts of the example until the leak stops, and following that process until only a concise example remain.

After deleting nearly everything the leak was still obvious, and made for a much easier time debugging. Ultimate the leak appears to be a v8 bug, but several work-arounds are possible. With one of those work-arounds, full re-instating the provided tests also no longer leak containers.

[rwjblue]

This should have been addressed by #12666, but I'm reopening so that we can confirm.

[shen6653]

Is this fix available for 1.13?

[stefanpenner]

Is this fix available for 1.13?

@shen6653 I don't know if it has been backported, we would likely accept a PR doing so.

[mixonic]

It seems like this just needs confirmation against the testing repo provided in the original ticket.

[oso-mate]

Forked the original leaker repo and upgraded to Ember 2.3.2. The memory leak issue seems to have been fixed for this version as part of: https://github.com/emberjs/ember.js/issues/12666

Performant tests timeline (2.3.2)

Notice even listeners seem to be properly handled.

Original tests timeline (1.13.10)

[stefanpenner]

The memory leak issue seems to have been fixed for this version as part of: #12666

to be pedantic, we are working around a v8 bug in that PR :trollface:

[calderas]

I just tested this again with the latest ember/ember-cli and looks so much better !!!
https://github.com/calderas/leaky-mcleakerson/tree/feature/ember-2.4.3

Memory doesn't increase between acceptance tests anymore

Thanks for the constant improvements !

[acorncom]

Per comments above, it looks like this there have been improvements. I'll close this for now, but please comment if we should re-open it.

[micky2be]

I would love to see a fix done for 1.13.x

I'm currently updating an app (quit big) from 1.12.2 to 2.x, and passing by 1.13 to fix all deprecation warning is a most.
So if we cannot run the tests of our app, it's gonna be very hard to know if any refactoring has been done correctly.

[Kuzirashi]

Is there any way to manually clear memory between acceptance tests run? I'm also interested in this. I doubt any fix will be backported to 1.13 and it's better to upgrade to Ember 2, but maybe there's some workaround?

[micky2be]

@Kuzirashi You could do like me.
I run multiple group of tests one by one with different filter.
It reloads PhantomJS, with fresh memory.
I've been surprise that by doing that it was faster than keeping the same instance of PahntomJS