[3.2.0-beta.2] Operand over 16-bits. Got 65536

[nullrocket]

After the fix for https://github.com/emberjs/ember.js/issues/16503 I updated from 3.0.0 and I am seeing this after a couple route transitions instead of the previous. I can't reproduce except in this application.

Error: Operand over 16-bits. Got 65536.
    at e.encode (encoder.js:26)
    at t.e.push (opcode-compiler.js:1001)
    at t.pushComponentDefinition (opcode-compiler.js:1831)
    at e.static (opcode-compiler.js:935)
    at xn (ember-glimmer.js:6472)
    at e.compile (opcode-compiler.js:385)
    at t.e.compileInline (opcode-compiler.js:784)
    at t.e.compileInline (opcode-compiler.js:1204)
    at opcode-compiler.js:170
    at e.compile (opcode-compiler.js:36)
    at _ (opcode-compiler.js:700)
    at t.e.add (opcode-compiler.js:794)
    at e.compile (opcode-compiler.js:684)
    at Object.evaluate (runtime.js:1146)
    at e.evaluate (runtime.js:32)
    at e.evaluateSyscall (runtime.js:3475)
    at e.evaluateInner (runtime.js:3447)
    at e.evaluateOuter (runtime.js:3439)
    at e.next (runtime.js:4828)
    at e.execute (runtime.js:4813)
    at i.handleException (runtime.js:4331)
    at e.handleException (runtime.js:4501)
    at e.throw (runtime.js:4238)
    at n.evaluate (runtime.js:1266)
    at e.execute (runtime.js:4225)
    at e.rerender (runtime.js:4527)
    at e.u.render (ember-glimmer.js:3785)
    at e.runInTransaction (ember-metal.js:997)
    at t.e._renderRoots (ember-glimmer.js:4066)
    at t.e._renderRootsTransaction (ember-glimmer.js:4099)
    at t.e._revalidate (ember-glimmer.js:4142)
    at e.invokeWithOnError (backburner.js:275)
    at e.flush (backburner.js:182)
    at e.flush (backburner.js:344)
    at e._end (backburner.js:815)
    at e.end (backburner.js:542)
    at e._run (backburner.js:854)
    at e._join (backburner.js:836)
    at e.join (backburner.js:597)
    at Array.<anonymous> (ember-glimmer.js:3896)
    at e._trigger (backburner.js:924)
    at e._end (backburner.js:827)
    at e.end (backburner.js:542)
    at e._run (backburner.js:854)
    at e._join (backburner.js:836)
    at e.join (backburner.js:597)
    at Function.E [as join] (ember-metal.js:406)
    at l (route-action.js:72)
    at n.sendAction (action_support.js:118)
    at n.tap (nb-button-like.js:73)
    at n.send (action_support.js:140)
    at n [as send] (ember-utils.js:341)
    at HTMLButtonElement._tap (nb-button-like.js:133)
    at Object.up (tap.js:90)
    at Object.gestureTrigger (dispatcher.js:265)

[tylerturdenpants]

@nullrocket I’m experiencing this same issue. Could you kindly explain how you integrated the fix for #16503 into your project? I’d like to start digging into this but I’m not sure how to get a local version on the VM connected to my project.

[nullrocket]

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 in https://github.com/emberjs/ember.js/issues/16503 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 this issue but if you switch ember-source to 3.1.0 you can duplicate the error for https://github.com/emberjs/ember.js/issues/16503

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

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

[krisselden]

@nullrocket thanks I found the caching issue with this, while the template and its handle is cached properly after the routes are first visited, the definition is given a new handle every lookup.

[krisselden]

It is worse, that issue only affects dynamic lookup via component helper, your reproduction is something else, I assumed that every compilable template stayed in a compiled state because all of them do but WrappedBuilder which handles components with a tagName in Ember. Meaning that every invoke of a component with a tag is regenerating all the opcodes, which is why you are hitting this limit.

[rwjblue]

https://github.com/emberjs/ember.js/pull/16557 bumped glimmer-vm to include a related fix, whcih was cherry-picked to beta in 9a88250 and to release in 1e55a63 (though release branch is actually on glimmer-vm v0.32.6).

Builds should be published for all channels (release, beta, and canary) soon. To test you can use:

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

Then update ember-source in your package.json to point at the tarball URL printed out from that command.

@krisselden - Would you mind reviewing and confirming that this is ultimately resolved (and close)?

[nullrocket]

@krisselden @rwjblue I ran it through a about 5k iterations of my reproduction and it seems to be fixed for me. No errors and no memory / heap growth.

[kiwiupover]

Thanks for the fast work on this today!

[rwjblue]

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.