Router Not Cleaned Up After Acceptance Tests

[jamesarosen]

I've been doing some memory profiling on my Ember app's tests suite. Our tests suites were failing in CI without providing any error message. After eliminating many other possible causes, I started to focus on out-of-memory errors.

Here are two heap snapshots from the same test run, about 20 seconds (or about 20 tests) apart: one, two

1. load these in Chrome
2. select the second snapshot
3. Click the dropdown that has the value "All Objects" and select "objects allocated between One and Two"
4. Sort by Retained Size

The top entry, Class is dominated by instances of router. The second, Array, is dominated by nextStates.

It seems that Ember.run(application, 'destroy'); does not properly clean up the Router and its internals.

[jamesarosen]

Here's a screenshot:

[stefanpenner]

can you provide an isolated reproduction please

[jamesarosen]

A bare Ember 1.13.11 app does not have this problem. I don't have any idea how to identify what part of our app (or what addon) is holding on to router references.

[jamesarosen]

Mirage also uses routers. It could be that.

No, that's not right. These routers have the page URLs, not API URLs in them.

[stefanpenner]

@jamesarosen if you can't narrow it down, we could find some time to screen share?

[jamesarosen]

Yes please!

I'll coordinate on Slack 😀

[stefanpenner]

i believe the issue was in an addon, such as ember-cli-mirage

[JackCA]

@jamesarosen do you remember what the issue was for this and how you solved it?

[jamesarosen]

I had two cases:

1. mirage, before Shutdown the pretender server on destroyApp. miragejs/ember-cli-mirage#281
2. Ember-I18n, though only when saving off service:i18n as window.Ember.i18n as required by https://github.com/DockYard/ember-validations