ember.js: Error after upgrading to Ember 2.4
This error only occurs after the app has been active and running for a while, giving the user a chance to navigate between several different routes. It’s very hard to reproduce, it seems to “just happen” after a while. We’ve been able to reproduce it a few times using our production build (ember.min.js), but never using a debug build (ember.debug.js).
Here is the stack:
"Cannot read property '_lookupFactory' of undefined"
TypeError: Cannot read property '_lookupFactory' of undefined
at i (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:7:2712)
at o (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:7:2833)
at Object.a [as default] (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:7:2888)
at Object.i [as subexpr] (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:6:4717)
at a (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16476)
at i (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16302)
at n (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16189)
at Object.r [as acceptHash] (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16075)
at n (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:26102)
at Object.a.inline (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:26664)
That seems to point back to the lookup-helper. The few times I’ve been lucky enough to catch this at a breakpoint, I’ve observed that the minified owner parameter becomes undefined. The rest of the env looks correct. See:

I know that’s very little to go on. Short of coming up with an easy way to reproduce this, is there any additional information about the stack that might helpful in debugging this?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 3
- Comments: 79 (51 by maintainers)
Commits related to this issue
- I think this may possibly workaround #13071 and is better anyway since this is a very hot path. — committed to emberjs/ember.js by krisselden 8 years ago
- [BUGFIX release] Fix for #13071 V8 inlining bug — committed to raido/ember.js by raido 8 years ago
- Merge pull request #13118 from raido/bug-fix-13071 [BUGFIX release] Fix for #13071 V8 inlining bug — committed to emberjs/ember.js by rwjblue 8 years ago
- [BUGFIX release] Fix for #13071 V8 inlining bug (cherry picked from commit a6b09b344ab871f088a58fc08d707809afceb36b) — committed to emberjs/ember.js by raido 8 years ago
- [BUGFIX release] Fix for #13071 V8 inlining bug (cherry picked from commit a6b09b344ab871f088a58fc08d707809afceb36b) — committed to emberjs/ember.js by raido 8 years ago
- [BUGFIX release] Fix for #13071 V8 inlining bug (cherry picked from commit a6b09b344ab871f088a58fc08d707809afceb36b) — committed to emberjs/ember.js by raido 8 years ago
- [BUGFIX release] Fix for #13071 V8 inlining bug (cherry picked from commit a6b09b344ab871f088a58fc08d707809afceb36b) — committed to emberjs/ember.js by raido 8 years ago
- Merge pull request #13116 from emberjs/try-13071-workaround Possible workaround for #13071 — committed to emberjs/ember.js by stefanpenner 8 years ago
v2.4.3 has been released with the work around added in https://github.com/emberjs/ember.js/pull/13118.
Just opened a V8 bug, https://bugs.chromium.org/p/v8/issues/detail?id=4839.
Sorry I still haven’t had any cycles to take a deeper look, hopefully soon.
OK, pulled https://github.com/emberjs/ember.js/issues/13118 into beta, release, and release-2-3 branches. The release and beta channels should get new builds shortly (via Travis) please bang on it for a while so we can confirm it does indeed fix this…
EDIT: The application linked below is using a build of ember which contains the workaround from PR #13118. It is no longer be valid for reproduction of this issue. If anyone is interested in reproducing this issue using our app, contact me and I could probably make that happen.
@stefanpenner So I did whittle down the reproduction by injecting some code into the page. Believe me, otherwise it would have been a nightmare.
This is still not 100% reproducible. If you follow these steps and it still hasn’t occurred, try restarting chrome all together.
Visiting this URL: https://qa-integration.batterii.com/#/community/MTpDb21tdW5pdHksOTAwMQ/room/MTpSb29tLDE5NzQ2MzAwMQ/wall/MTpSb29tLDE5NzQ2MzAwMSxXYWxsLDEwMDAx
Login with email:
emberdev@batterii.comand password:tomster1. That should deeplink you into a page that looks like this:After logging in and landing on the above page, you’ll need to refresh (so that you start clean from that page).
Open your chrome debugger and run the following in the console:
Set Chrome Debugger to “Pause on Caught Exceptions”.
The injected code should have added a button in the upper right corner. Click that button. First a new tab will open and trigger a file to be downloaded, then a modal dialog should open and close several times. That modal is actually “routable” so you should also observe the route changing. On the second or third open of the modal, you should hit the exception. If this doesn’t occur, refresh the browser and try again (starting with step 4).
I’ll work on getting you source code in the meantime. We run on Google App Engine so you will still have to connect to a cloud server, but I should be able to arrange it so you can run the client app locally (proxying to a cloud server).
Lastly, I’m on slack now and will be until about 4PM EST. I’d be happy to screenhero if need be. I’ll also be available all day tomorrow.
🎊 🎉 I tested @raido’s PR and I cannot reproduce the issue. That does seem to be a successful workaround. 😄
Edit: Tested with Chrome 49 and Chrome 51.
Oh man, the hours I spent trying to reproduce/fix this bug before finding this thread… ugh. Good work guys!
We’ve also been experiencing this issue and this appears to have fixed it. I’ve been hammering our site against the
ember#9c3e5820build for over an hour now and haven’t seen any issues.Good job all!
@2468ben i wonder if we should maybe have a hesienbug/maybe vmbug label?
@typeoneerror fwiw I’m personally very happy to have people report that they experience the same bug while also providing environment details.
I’m not sure who exactly is supposed to be harmed by such reports 😉
In response to the question above, if this is v8/Chrome only: checked our logs, found 8 cases, all Chrome (49/48) on Windows (7 and 10). Unfortunately I don’t have more data points.
@givanse we’ve upgraded to Ember 2.12 by now and don’t seem to have this issue anymore
we’re currently running an app on
ember@2.4.6and we’re hitting this exact issue according to Sentry even though the code includes the workaround in https://github.com/emberjs/ember.js/pull/13118 😞I have been trying to follow the reported scenarios closely, but I believe this code is in Ember 2.3 also. Does Ember 2.3 also suffer this issue?
@workmanw Can you test the PR that i made based on https://bugs.chromium.org/p/v8/issues/detail?id=4839#c9 comment?
PR https://github.com/emberjs/ember.js/pull/13118
With this change i have not been able to crash my app. If i revert the changes, it pretty much instantly starts to crash.
I’ve been seeing this since the start of February (2.3, then 2.4), OSX and Windows, Chrome only. Removing all custom Em.Helper.helpers and ember-truth-helpers stopped the errors from appearing (of course).
It’s been a while since I ran into a bug that made me brush off my tinfoil hat. You are not alone. The truth is out there.
A :sadpanda: work-around, is to force the function to exceed the max AST that can be inlined. This should allow you to 🚢
putting the following string in that function’s body, should do the trick (right now, these limits/heuristics change overtime)
What’s even more odd is that you can see in the last screenshot, there is
var s = "helper:" + e;on line 8786 … but somehow on the very next linesis undefined. 😕 It’s almost as if the stack is getting borked … or the chrome debugger is just getting it wrong.