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:

image image

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

Most upvoted comments

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.

  1. Visiting this URL: https://qa-integration.batterii.com/#/community/MTpDb21tdW5pdHksOTAwMQ/room/MTpSb29tLDE5NzQ2MzAwMQ/wall/MTpSb29tLDE5NzQ2MzAwMSxXYWxsLDEwMDAx

  2. Login with email: emberdev@batterii.com and password: tomster1. That should deeplink you into a page that looks like this:

image

  1. After logging in and landing on the above page, you’ll need to refresh (so that you start clean from that page).

  2. Open your chrome debugger and run the following in the console:


(function() {
var room = 'MTpSb29tLDE5NzQ2MzAwMQ',
    wall = 'MTpSb29tLDE5NzQ2MzAwMSxXYWxsLDEwMDAx',
    wallitem = 'MTpXYWxsSXRlbSwxOTg0NjMwMDQ';

function promiseTimer(ms) {
  return new Ember.RSVP.Promise(function(resolve) {
    Ember.run.later(resolve, ms);
  });
}

function timedTransition() {
  return BC.router.transitionTo.apply(BC.router, arguments).then(function() {
    return promiseTimer(800);
  });
}

function takeActions() {
  var downloadUrl = window.wallitemRecord.get('downloadUrl');
  window.open(downloadUrl);
  promiseTimer(1400).then(function() {
    return timedTransition('wall.wallitem', room, wall, wallitem);
  }).then(function() {
    return timedTransition('wall', room, wall);
  }).then(function() {
    return timedTransition('wall.wallitem', room, wall, wallitem);
  }).then(function() {
    return timedTransition('wall', room, wall);
  }).then(function() {
    return timedTransition('wall.wallitem', room, wall, wallitem);
  }).then(function() {
    return timedTransition('wall', room, wall);
  }).then(function() {
    return timedTransition('wall.wallitem', room, wall, wallitem);
  }).then(function() {
    return timedTransition('wall', room, wall);
  }).then(function() {
    return timedTransition('wall.wallitem', room, wall, wallitem);
  }).then(function() {
    return timedTransition('wall', room, wall);
  });
}

BC.store.findRecord('wallitem', wallitem).then(function(wallitem) { window.wallitemRecord = wallitem; });
$('<button id="crash-reproduce">Crash Reproduce</button>').appendTo('.top-right-nav');
$('#crash-reproduce').on('click', takeActions);
})();
  1. Set Chrome Debugger to “Pause on Caught Exceptions”.

  2. 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).

image


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#9c3e5820 build 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.6 and 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)

"Pork chop porchetta rump, bacon turducken filet mignon tri-tip drumstick picanha beef ribs sausage salami. Leberkas beef landjaeger bresaola, sausage meatloaf pastrami frankfurter ribeye jowl turducken drumstick flank. Pork loin shank tongue leberkas ham strip steak salami swine short ribs cupim. Strip steak sausage turkey tenderloin, alcatra turducken porchetta ribeye brisket spare ribs rump salami ground round tail frankfurter. Kielbasa cow porchetta, hamburger jowl salami turducken capicola beef. Corned beef meatloaf ball tip landjaeger shank pork belly. Short loin kielbasa pig tail, brisket cupim salami andouille hamburger sausage short ribs."

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 line s is undefined. 😕 It’s almost as if the stack is getting borked … or the chrome debugger is just getting it wrong.