Array buffer allocation failed during ember test

I recently updated ember-qunit to latest which also required me to install qunit and @ember/test-helpers manually. I noticed that when I would run my ~7000 unit tests that I would run into an error like this:

not ok 1889 Chrome 92.0 - [1221 ms] - Unit | Component | <myComponent>
    ---
        actual: >
            null
        stack: >
            RangeError: Array buffer allocation failed
                at new ArrayBuffer (<anonymous>)
                at new Int32Array (<anonymous>)
                at new HeapImpl (http://localhost:9001/assets/vendor.js:70039:19)
                at artifacts (http://localhost:9001/assets/vendor.js:70301:13)
                at new Renderer (http://localhost:9001/assets/vendor.js:35061:52)
                at new InteractiveRenderer (http://localhost:9001/assets/vendor.js:35316:3)
                at Function.create (http://localhost:9001/assets/vendor.js:35325:14)
                at FactoryManager.create (http://localhost:9001/assets/vendor.js:25093:25)
                at Proxy.create (http://localhost:9001/assets/vendor.js:24811:20)
                at instantiateFactory (http://localhost:9001/assets/vendor.js:24912:71)

To be honest, not sure where to go from here. Any advice would be appreciated.

ember-cli: 3.24.0
node: 14.17.3
nom: 6.14.13

[tkraak]

@monovertex thanks for sharing your findings in such great detail. It’s very impressive and much appreciated.

This seems to confirm our earlier inclination that this is a bug in Chrome since our test suite runs just fine in Firefox.

[monovertex]

TLDR: There seems to be an issue with WeakMaps in Chrome (starting with 92.0.4515.107-1), and adding some extra testing teardowns or using an older Chrome version to run the suite no longer triggers this error in our case.

Long version:

After some further investigation with v5.1.4, in our case it seems this is somehow related to WeakMaps in Chrome. This might be caused by slow GC, not necessarily a memory leak, but I’m not yet sure.

The biggest retainer I’ve encountered is DESTROYABLES_META, which retains references to basically any destroyable, as seen below:

I added the following code in test-setup.js to handle this:

QUnit.testStart(function () {
    enableDestroyableTracking();
    assertDestroyablesDestroyed();
});

This effectively resets the DESTROYABLES_META WeakMap on each test start.

After this change the tab no longer goes over 500MB of memory usage, but at some point I still start getting the allocation failed error.

Some further analysis reveals that the -top-level-view:main entity registered by @ember/test-helpers is also retained in a WeakMap, as seen below:

I added the following code in test-setup.js to try to teardown this as well:

const application = Application.create(config.APP);

QUnit.testDone(function () {
    application._applicationInstances.forEach((appInstance) => {
        appInstance.unregister('-top-level-view:main');
    });
});

But unfortunately this is done too late, as at this point the instances array is already empty. Instead I wrote a wrapper for setupRenderingTest that adds the following teardown:

hooks.afterEach(function () {
    this.owner.unregister('-top-level-view:main');
});

And this finally does the trick, but it is still a workaround, and doesn’t explain or handle the underlying issue.

My colleague @cristi-badila suggested to try an older Chrome version to run the suite (we tried 81.0.4044.92-1, Ubuntu 64bit, from Feb 2020 at first), and sure enough the error does not pop up with this version, which further confirms that this is indeed a Chrome issue.

I then started bisecting the versions (with 94 being the latest version) to figure out where the issue started occurring, as follows:

• 87.0.4280.66-1 => passes
• 91.0.4472.77-1 => passes
• 93.0.4577.63-1 => fails
• 92.0.4515.107-1 => fails
• 91.0.4472.164-1 => passes

It is now pretty obvious that for our suite at least, the Chrome version makes the difference, and 92.0.4515.107-1 is the first one that caused this change. I am not sure if this is a bug in Chrome, and how to proceed on this issue.