search

emberjs / ember.js

Ember.js - A JavaScript framework for creating ambitious web applications
https://emberjs.com
MIT License
22.46k stars 4.21k forks source link

Error after upgrading to Ember 2.4 #13071

Closed workmanw closed 8 years ago

workmanw commented 8 years ago

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?

fotinakis commented 8 years ago

I also just hit this for the first time in production (and happened to remember seeing this discussion on Twitter). Chrome 48.0.2564.116 and Ember 2.3.

workmanw commented 8 years ago

Chatted w/ @krisselden on Slack. Yes, I'd be happy to try out a PR. My reproduction rate is about 33% of the time (so rather frequently).

krisselden commented 8 years ago

@workmanw you can tryout the above by cloning the ember repo and using curl https://github.com/emberjs/ember.js/pull/13116.patch | git am and doing npm run build and using dist as your bower_components/ember

workmanw commented 8 years ago

@krisselden Unfortunately, that did not seem to make a difference :(

I checked out v2.4.2, applied the patch and did a build. Copied ember.min.js to my app/bower_components/ember/ember.debug.js. Removed the tmp/ directory and fired up the server. I confirmed that the patch had been applied by looking at the sources tab.

In case someone wanted to double check, here is the hash after my patch and build: MD5 (dist/ember.min.js) = 23ab1021bebdf170d21338fecf347937

Happy to keep trying ideas you might have.

krisselden commented 8 years ago

@workmanw based on the last comment on the https://bugs.chromium.org/p/v8/issues/detail?id=4839#c7 and looking at the code, are you using local helper lookup? I'm guessing _findHelper is being inlined here https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/lib/system/lookup-helper.js#L62 when it has never seen this case to be true and when you navigate to a route where it becomes true hasRegistration the inlined code doesn't have owner for the deopt.

krisselden commented 8 years ago

My current thought is https://github.com/emberjs/ember.js/commit/8af7da67c4b1eab94a6adfc82c91af98dc3ee532 is triggering the bug in v8 and that preventing _findHelper from inlining or warming the branch with a local helper would resolve it until the bug is fixed in v8.

raido commented 8 years ago

@krisselden If you have anything ready for testing, i can try it out. My reproduction rate is about the same as @workmanw's.

raido commented 8 years ago

@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.

workmanw commented 8 years ago

:confetti_ball: :tada: I tested @raido's PR and I cannot reproduce the issue. That does seem to be a successful workaround. :smile:

Edit: Tested with Chrome 49 and Chrome 51.

rwjblue commented 8 years ago

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?

raido commented 8 years ago

Yes, i can confirm that Ember v2.3 is affected by this too.

rwjblue commented 8 years ago

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

2468ben commented 8 years ago

@workmanw @raido Thank you so much for spending so much time reproducing the bug, working with Chromium to find & fix this issue. It's one of those Heisenbugs where, trying to be a responsible OSS user, I waited to file an issue for over a month because I couldn't make a stable gist/twiddle/bin/etc. It just defied so much logic that I figured it must be my fault. Next time I'll be more proactive and ping the Slack room for fellow victims.

stefanpenner commented 8 years ago

Good job all!

@2468ben i wonder if we should maybe have a hesienbug/maybe vmbug label?

stefanpenner commented 8 years ago

[fixed by #13118]

workmanw commented 8 years ago

:)

@rwjblue I've updated my bower.json now to use "ember": "components/ember#9c3e5820" and I'm going to send it through the QA cycle. I'll let you know if any issues popup.

rwjblue commented 8 years ago

Thank you very much!

chrisdoornink commented 8 years ago

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.

rwjblue commented 8 years ago

v2.4.3 has been released with the work around added in https://github.com/emberjs/ember.js/pull/13118.

courthead commented 8 years ago

Oh man, the hours I spent trying to reproduce/fix this bug before finding this thread... ugh. Good work guys!

Turbo87 commented 7 years ago

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 😞

workmanw commented 7 years ago

@Turbo87 This issue was also fix in Chrome as well. So there should only be 1 or 2 versions of Chrome that could run into this.

Are you sure it's the same issue?

Turbo87 commented 7 years ago

@workmanw yeah, pretty sure it's the same. apparently some of our users are still running old Chrome versions and in fact some derived browsers (Sogou Explorer, Opera, Chromium, Dragon) are showing similar behavior according to our Sentry logs

workmanw commented 7 years ago

:(. I feel your pain. Some of our customers are enterprises that lock users into specific versions of Chrome and never let them upgrade.

It's possible that this issue resurfaced in some way. I can say with 100% certainty that, at the time, this workaround did resolve the issue for us (v2.4.3).

raido commented 7 years ago

Same here.

krisselden commented 7 years ago

@Turbo87 do you have specific versions?

Turbo87 commented 7 years ago

Chrome 49 is by far the most common one for some reason

givanse commented 6 years ago

@Turbo87 did you ever found a way around this problem?

Turbo87 commented 6 years ago

@givanse we've upgraded to Ember 2.12 by now and don't seem to have this issue anymore