ember.js: Uncaught TypeError: Cannot read property 'syscall' of null

I have been banging my head against this every time I try to update from 3.0.0 to any >= 3.1 version beta or final.
It happens after transitioning in and out of a particular route exactly 3 times. Unfortunately I’m unable to create a reproduction except in this application and the stacktrace doesn’t point to anything I can dig into. Any idea where I can start looking?

AppendOpcodes.prototype.evaluate = function evaluate(vm$$1, opcode, type) {
            var operation = this.evaluateOpcode[type];
             if (operation.syscall) {  // here is where it errors.  type argument is 0
                operation.evaluate(vm$$1, opcode);
            } else {
                operation.evaluate(vm$$1.inner, opcode);
            }
        };

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 43 (21 by maintainers)

Most upvoted comments

Apologies if I’m incorrect here, but I may have a minimal reproduction of this issue that works in dev?

I have a full app that tends to throw this syscall error and then render the entire app 3 times in a row any time I hit a compilation error.

I was able to reproduce the issue that I’m experiencing just by generating a new app with 3.15.1, then creating an index template containing a nonsense component name (to create a compilation error).

ember-cli: 3.15.1
node: 10.18.0
os: darwin x64

Reproduction repo is here: https://github.com/sethbrasile/possible-ember-issue-reproduction-16503

sethbrasile on Jan 13, 2020

We have encountered such error on 3.5. Any ideas?

iorlas on Nov 22, 2018

Edited ~~I have a reproduction now, I am pretty sure it is related to usage of the {{component}} helper in an {{each}} block~~ After reading @willviles comment I went back and simplified my reproduction some more, it doesn’t take a {{component}} or {{each}} to reproduce as I initially thought. I removed the each and just pasted in a large number of components to simulate the number being rendered in the each I had previously set up.

The reproduction transitions between two routes with this template in each route, after some number of transitions it will throw the error. Currently it throws the error I’m experiencing in https://github.com/emberjs/ember.js/issues/16532 but if you switch ember-source to 3.1.0 you can duplicate this error

{{my-component text=item}}
{{my-component text=item}}
... about 600 more

https://github.com/nullrocket/glimmer-crash

nullrocket on Apr 17, 2018

Closing this issue as the underlying bug has been fixed (and confirmed with the demo repos provided). The fix for this has been pulled into release (for 3.1.x release) and beta (for 3.2.0-beta.x release). The latest builds (in 10-15 minutes) to the release, beta, and canary channels should include the fix (you can get the latest tarball URL via ember-source-channel-url).

If additional issues crop up, we should report as a new issue with a reproduction.

rwjblue on Apr 21, 2018

Awesome, thank you for testing! I’ll try to take some time today and poke at things with @krisselden to try and see if we have another underlying issue before releasing 3.1.1. Will try to update here to let y’all know…

rwjblue on Apr 17, 2018

@krisselden - Agreed, reopened. 😃

@nullrocket / @willviles - Can you test with the latest release build to confirm it is working?

The following will get you the current tarball URL:

npm install -g ember-source-channel-url
ember-source-channel-url release

Then you can update your package.json to have:

  “ember-source”: “<URL printed above>”,

rwjblue on Apr 17, 2018

If I look at the implementation of the class Heap, I notice that the buffer uses a TypedArray

this.heap = new Uint16Array(0x100000);

If something is pushed on the heap, then there is no size checking:

  push(item: number): void {
    this.heap[this.offset++] = item;
  }

This is a problem with TypedArray as they don’t expand if needed as regular arrays does.

A simple test

let heap = new Uint16Array(2);
heap.length;

produces 2

heap[3]=1;
heap.length;

produces 2

pieter-v on Apr 12, 2018

I suspect what’s happening is that an exception is getting thrown somewhere during render that we’re not catching and cleaning up appropriately.

I can definitely confirm that suspicion. Every instance of the syscall error that I see in our sentry logs has some other error in the log before it. As mentioned in https://github.com/emberjs/ember.js/issues/16503#issuecomment-387330295, a lot of the times factoryManager.create() seems to be involved in the original error, but according to Sentry that was apparently already an issue before we upgraded to Ember 3.0/3.1.

Turbo87 on May 29, 2018

I tested https://github.com/nullrocket/glimmer-crash/compare/each-component-3-1-0 with the changes from https://github.com/emberjs/ember.js/pull/16558 linked locally, and after running through all 200 iterations there is no heap growth.

rwjblue on Apr 20, 2018

I’m experiencing the same issue since upgrading to Ember 3.1.1.

In my app, it occurs after transitioning between two ‘tab’ states multiple times (between 5-10 transitions) and errors on a tab’s child component scheduling a function using Ember runloop’s next. The child component is not being rendered using the component helper.

I can prevent the error by using once instead, but this is not a solution as it locks up the thread quite perceptibly.

willviles on Apr 17, 2018