Ember.js: Erreur après la mise à niveau vers Ember 2.4

Ce qui est encore plus étrange, c'est que vous pouvez voir dans la dernière capture d'écran, il y a var s = "helper:" + e; sur la ligne 8786 ... mais d'une manière ou d'une autre, sur la ligne suivante, s n'est pas défini. : confused: C'est presque comme si la pile s'embrouillait ... ou si le débogueur de chrome se trompait.

J'ai vu quelque chose comme ça aussi. Cela arrive rarement et je ne sais pas comment me reproduire. De plus, je ne sais pas si c'est le problème de mon application ou autre chose.

@raido est-ce que votre stack est le même que le mien (IE l'échec est sur _lookupFactory )? Êtes-vous sur Ember 2.4.1? Avez-vous vu ce problème sur les versions précédentes de braise?

Nous avons mis à jour Ember 2.2 => Ember 2.4 et avons commencé à voir ce problème assez lourdement dans nos journaux de serveur en quelques jours.

: +1: vu cela moi-même et m'a confus, à partir de mes journaux de bugsnag:

11779      if (validateLazyHelperName(name, owner, env.hooks.keywords)) {
11780        var helperName = 'helper:' + name;
11781        if (owner.hasRegistration(helperName, options)) {
11782          helper = owner._lookupFactory(helperName, options);
11783        }
11784      }
11785    }

Comme vous le dites, comment owner peut-il être undefined sur la ligne 11782 s'il dépasse le owner.hasRegistration la ligne précédente?

De même, il ne l'a vu en production qu'une fois minifié (ci-dessus provient de sourcemaps).

Les journaux montrent que nous ne l'avons vu que sur Chrome jusqu'à présent.

@workmanw Oui, mon erreur est également liée à _lookupFactory et est voir lookupHelper dans le stacktrace.

Journaux de la version de production, arrivé tout à l'heure avec la v2.3.0

TypeError: Cannot read property '_lookupFactory' of undefined
    at o (vendor-6292d0672068025de3c6d57c1fb505d0.js:7)
    at Object.a [as default] (vendor-6292d0672068025de3c6d57c1fb505d0.js:7)
    at Object.r [as lookupHelper] (vendor-6292d0672068025de3c6d57c1fb505d0.js:6)
    at Object.D [as inline] (vendor-6292d0672068025de3c6d57c1fb505d0.js:16)
    at Object.i.inline (vendor-6292d0672068025de3c6d57c1fb505d0.js:16)
    at l.populateNodes (vendor-6292d0672068025de3c6d57c1fb505d0.js:16)
    at l.render (vendor-6292d0672068025de3c6d57c1fb505d0.js:16)
    at i (vendor-6292d0672068025de3c6d57c1fb505d0.js:16)
    at vendor-6292d0672068025de3c6d57c1fb505d0.js:16
    at s (vendor-6292d0672068025de3c6d57c1fb505d0.js:16)

Je peux confirmer ce problème sur 2.4.2, le voyant parfois en production, pas encore vu en développement. Cela peut-il être causé par l'inspecteur des braises?

Pour plus d'informations: jamais eu cela sur 2.3.x et la pile est la même (_lookupFactory)

EDIT: Je peux confirmer qu'il ne s'agit pas d'un problème de braise-inspecteur, une erreur s'est produite alors que l'inspecteur était désactivé.

Bogue confirmé dans 2.4.1 et 2.4.2. Se produit uniquement avec js minifié

@jcbvm @ gdub22 L' un de vous a-t-il pu le reproduire de manière cohérente? J'ai essayé et essayé de trouver au moins un ensemble d'étapes cohérent dans notre application dans l'espoir de créer un braise-twiddle, mais je n'ai pas eu de chance.

Ceci est complètement anecdotique et probablement un hareng rouge, mais cela semble se produire en essayant de rendre un assistant qui a un composant ancêtre rendu avec le composant assistant ( {{component componentName}} ).

@workmanw De même, nous n'avons pas pu reproduire de manière cohérente, nous utilisons beaucoup l'aide {{component}} dans toute notre application.

@workmanw n'est pas cohérent à 100% mais je pense que je l'ai réduit à un composant particulier qui utilise l'assistant de composant dans son propre modèle.

Uglify transpile la fonction ci-dessus en:

function n(e,t,r,n){
  var i=r.helpers[e];
  if(!i){
    var o=r.owner;
    if (a(e,o,r.hooks.keywords)){
      var s="helper:"+e;
      o.hasRegistration(s,n) && (i=o._lookupFactory(s,n));
    }
  }
  return i;
}

Notez que les deux accès aux propriétés sur owner ont été compilés sur une seule ligne. Je suppose que le crash se produit réellement sur le premier et que la fidélité du sourcemap n'est pas assez élevée pour les distinguer correctement.

Modifié pour ajouter: Ah, mais le crash est définitivement pour un _lookupFactory property , donc ma spéculation doit être fausse. Curieux et curieux.

@ ef4 Peut-être ... mais les quelques fois où j'ai o (dans votre extrait de code) n'est pas défini, mais r.owner est un propriétaire valide. En fait, je suis capable de faire r.owner.hasRegistration(s,n) && (r.owner._lookupFactory(s,n)); et d'obtenir la classe. Certes, c'est après que Chrome a cassé sur une exception interceptée ... donc le débogueur pourrait également être dans un état trompeur.

@ ef4 oui c'est vraiment étrange.

V8 pourrait-il l'optimiser pour une raison quelconque? Qui en sait le plus sur les arts sombres du V8, peut-être @stefanpenner ?

Si le code de ligne qui plante est:

o.hasRegistration(s,n) && (i=o._lookupFactory(s,n));

puis:

1. o.hasRegistration(s,n) a déjà renvoyé une valeur de vérité; ça signifie
2. o n'est ni null ni undefined ; par conséquent
3. Cannot read property '_lookupFactory' of undefined est soit faux, soit un bogue dans la v8

Est-ce que je rate quelque chose d'évident?

Pour les personnes qui ont reproduit ce problème, quelle version de Chrome utilisez-vous? L'avez-vous reproduit dans Firefox, IE ou Safari?

@wycats Je ne vois rien qui vous manque. Ce sont les mêmes conclusions auxquelles je suis arrivé. Nous n'avons vu ce problème enregistré que sur Chrome le plus récent (48). Lors de mes tests de reproduction, j'utilisais 48.0.2564.116. Personnellement, je n'ai pas essayé Firefox, IE ou Safari, mais je vais les essayer et faire un rapport.

EDIT: Je ne peux pas simplifier le problème au point de produire un twiddle. Mais si cela peut être utile, je peux mettre en file d'attente une ou plusieurs échecs interrompus à un point d'arrêt et sauter sur un héros de l'écran si quelqu'un veut fouiller dans le débogueur de chrome. Parfois, je peux le reproduire 3 fois en une minute. Parfois, cela prend 20 minutes ou plus.

@wycats Très bien. J'ai passé la dernière heure à essayer Chrome, Safari et Firefox. J'ai pu le reproduire plusieurs fois dans Chrome et pas du tout dans Safari et Firefox. Je ne suis pas sûr que ce soit concluant, mais cela pointe certainement de plus en plus vers un problème spécifique à Chrome.

Tout cela me rappelle http://yehudakatz.com/2010/01/02/the-craziest-fing-bug-ive-ever-seen/

Je n'ai pas pu non plus le reproduire. Pour moi, cela se produit généralement lorsque l'application démarre. Le rechargement de l'application plusieurs fois la plante probablement, mais ce n'est pas cohérent. Il peut planter 5 fois en quelques minutes ou prendre une demi-heure. J'ai testé sur le dernier Chrome.

@workmanw Je recommanderais de forcer cette fonction à rester dans des modes spécifiques, cela peut nous aider à en savoir plus sur le problème. À ce stade, nous devrions également envoyer un ping à nos amis v8. Mais pour cela, une reproduction (même une application complète) sera probablement nécessaire.

Pour conserver les fonctions dans des modes spécifiques, vous pouvez désactiver lentement certaines parties de la v8 et voir si le bogue s'arrête. Cela nous aidera à nous rapprocher de la cause profonde.

d'abord, je désactiverais simplement l'inlining, en exécutant chromes v8 avec elle désactivée: --nouse_inlining (je suppose que cela peut être suffisant)

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --js-flags="--nouse_inlining" --user-data-dir=/tmp/foobar

D'un autre côté, essayez de désactiver le vilebrequin tous ensemble --crankshaft=false

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --js-flags="--crankshaft=false" --user-data-dir=/tmp/foobar

@stefanpenner

J'ai testé cela en utilisant Chrome 48 (plutôt que Canary). Si vous souhaitez que j'essaye avec Canary, je serais ravi de le faire.

Avec --nouse_inlining je n'ai pas pu reproduire ce problème.
Avec --crankshaft=false j'ai pu reproduire ce problème.

À ce stade, nous devrions également envoyer un ping à nos amis v8. Mais pour cela, une reproduction (même une application complète) sera probablement nécessaire.

Je comprends parfaitement. J'ai passé environ 4 heures à essayer de "travailler en avant" et de construire un Ember-twiddle qui reproduit cela. Je ne comprends tout simplement pas assez ce qui se passe pour faire cela. Alors maintenant, je vais commencer à "travailler à l'envers" en utilisant notre application pour simplifier la reproduction en réduisant les étapes de reproduction et en arrachant autant que possible notre application.

Avec --nouse_inlining, je n'ai pas pu reproduire ce problème.

semble attendu, donc c'est probablement lié à un bogue en ligne.

Avec --crankshaft = false, j'ai pu reproduire ce problème.

c'est peut-être le mauvais drapeau, je ne m'en souviens pas.

Je comprends parfaitement. J'ai passé environ 4 heures à essayer de "travailler en avant" et de construire un Ember-twiddle qui reproduit cela. Je ne comprends tout simplement pas assez ce qui se passe pour faire cela. Alors maintenant, je vais commencer à "travailler à l'envers" en utilisant notre application pour simplifier la reproduction en réduisant les étapes de reproduction et en arrachant autant que possible notre application.

@workmanw est-il possible de partager l'application (ou une URL vers l'application) telle
La réalité est que reproduire cela isolément peut être délicat.

R: sadpanda: le contournement, consiste à forcer la fonction à dépasser le maximum AST qui peut être intégré. Cela devrait vous permettre de: expédier:

mettre la chaîne suivante dans le corps de cette fonction , devrait faire l'affaire (pour le moment, ces limites / heuristiques changent avec le temps)

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

@workmanw si vous pouvez également enregistrer Canary, ce serait pratique.

@stefanpenner

mettre la chaîne suivante dans cette fonction, devrait faire l'affaire (pour le moment, cela peut changer les heures supplémentaires)

Votre connaissance de l'intérieur ne cesse de m'étonner.

@workmanw est-il possible de partager l'application telle

Oui, je devrais pouvoir y arriver. Si vous me donnez un peu de temps, je fournirai des informations d'identification à l'un de nos environnements de pré-production et je préparerai les données. Je pourrais probablement accepter de partager la source si nécessaire, mais je devrais le faire en privé.

@workmanw si vous pouvez également enregistrer Canary, ce serait pratique.

Terminé. J'ai vérifié la "version 51.0.2673.0 canary (64 bits)" de Canary sans aucun des drapeaux et malheureusement je pouvais toujours le reproduire.

Je pourrais probablement accepter de partager la source si nécessaire, mais je devrais le faire en privé.

Cela m'aiderait personnellement à essayer de réduire davantage le problème, sans aucune garantie. J'aimerais plus ou moins faire ce qui suit:

• préparer une reproduction pour les gens du V8
• explorer une solution provisoire [BUGFIX]
• obtenir un rapport sur le V8 (aujourd'hui / ce week-end)

Avec une application en face de moi (où je peux changer le code + explorer), découvrir une solution de contournement / reproduction appropriée pourrait être possible.

EDIT: L'application liée ci-dessous utilise une version de braise qui contient la solution de contournement de PR # 13118. Il n'est plus valable pour la reproduction de ce numéro. Si quelqu'un souhaite reproduire ce problème à l'aide de notre application, contactez-moi et je pourrais probablement y arriver.

@stefanpenner J'ai donc réduit la reproduction en injectant du code dans la page. Croyez-moi, sinon cela aurait été un cauchemar.

Ce n'est toujours pas reproductible à 100%.

1) Visite de cette URL: https://qa-integration.batterii.com/#/community/MTpDb21tdW5pdHksOTAwMQ/room/MTpSb29tLDE5NzQ2MzAwMQ/wall/MTpSb29tLDE5NzQ2MzAwDEMSxXYWxs

2) Connectez-vous par e-mail: [email protected] et mot de passe: tomster1 . Cela devrait vous relier à une page qui ressemble à ceci:

3) Après vous être connecté et avoir atterri sur la page ci-dessus, vous devrez actualiser (afin de commencer à nettoyer à partir de cette page).

4) Ouvrez votre débogueur Chrome et exécutez ce qui suit dans la 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);
})();

5) Réglez Chrome Debugger sur "Pause on Caught Exceptions".

6) Le code injecté devrait avoir ajouté un bouton dans le coin supérieur droit. Cliquez sur ce bouton. Tout d'abord, un nouvel onglet s'ouvre et déclenche le téléchargement d'un fichier, puis une boîte de dialogue modale doit s'ouvrir et se fermer plusieurs fois. Ce modal est en fait "routable" donc vous devriez également observer le changement de route. À la deuxième ou troisième ouverture du modal, vous devez frapper l'exception. Si cela ne se produit pas, actualisez le navigateur et réessayez (en commençant par l'étape 4).

Je vais travailler pour vous obtenir le code source en attendant. Nous fonctionnons sur Google App Engine, vous devrez donc toujours vous connecter à un serveur cloud, mais je devrais pouvoir l'organiser pour que vous puissiez exécuter l'application client localement (proxy vers un serveur cloud).

Enfin, je suis en relâche maintenant et le serai jusqu'à environ 16 heures HNE. Je serais heureux de screenhero si besoin est. Je serai également disponible toute la journée demain.

Superbes étapes de repro!

J'exécute des tâches actuellement, mais j'essaierai d'enquêter plus tard dans la journée (ou demain matin).

@stefanpenner Merci beaucoup! Je serai en ligne toute la journée demain et heureux de vous aider si nécessaire. Vous pouvez me trouver dans le mou des braises. Je vous ai également envoyé un e-mail pour accéder à notre code source (envoyé par e -mail à votre

@stefanpenner Pour info, j'ai légèrement modifié les étapes. J'ai trouvé qu'il était beaucoup plus probable que vous reproduisiez le problème si vous utilisez la liste "mode maçonnerie" de notre application. Tout ce qui a changé était l'URL à l'étape 1, la capture d'écran sous l'étape 2 et l'extrait de code à l'étape 4.

_En réponse à la question ci-dessus, s'il s'agit de v8 / Chrome uniquement: _ vérifié nos journaux, trouvé 8 cas, tous Chrome (49/48) sur Windows (7 et 10). Malheureusement, je n'ai pas plus de points de données.

J'ai essayé de reproduire cela mais sans chance sur Twiddle et localement. Mais cela semble être spécifique aux helpers, car j'ai une autre application en production sans helpers et elle ne plante pas, prenez-la avec du sel.

J'ai fait quelques tests de force brute en forçant l'application à naviguer entre les routes d'avant en arrière et parfois un bogue se produisait après 3 transitions, lançait l'erreur et en récupérait avec la transition suivante et après la récupération ne semblait plus jamais planter.

Edit: Je l'ai laissé naviguer à travers 7 itinéraires pendant 300 fois, avec un délai de 50 ms entre les transitions et rien ne se casserait. Est-ce que 5 recharges manuelles après cela et il s'est écrasé au démarrage lors du rendu initial "index route" où se trouvent des helpers dans les modèles.

J'ai fait quelques tests de force brute en forçant l'application à naviguer entre les routes d'avant en arrière et parfois un bogue se produisait après 3 transitions, lançait l'erreur et en récupérait avec la transition suivante et après la récupération ne semblait plus jamais planter.

Cela décrit absolument mon expérience.

Dans notre cas, nous utilisons window.open pour déclencher un téléchargement de fichier et cette action «semble» aider à augmenter le risque que ce problème se produise (mais cela pourrait être un hareng). Pour moi, parfois je suis sur une lancée et cela se produira 10 fois sur 10 après la 3e ou la 4e transition. D'autres fois, cela n'arrivera pas une fois dans une demi-heure.

@workmanw J'ai un tas de choses de type "probablement hotte" qui "semblent" aider à le reproduire mais en réalité je n'ai pu suivre aucune des "astuces" que l'application m'a données. Cela semble complètement aléatoire.

J'ai également essayé de planter votre application par les étapes de reproduction données ici, cela ne s'est pas produit.

@stefanpenner J'ai essayé d'ajouter une "côtelette de porc" au corps de fonction, je n'ai pas semblé aider ou j'ai fait quelque chose de mal.

Quoi qu'il en soit, je pense avoir un moyen de faire en sorte que cela se produise plus souvent. J'ai maintenant confirmé que c'est toujours le même assistant:ce qui le plante dans mon application. Je vais continuer à creuser.

Jusqu'à présent, j'ai réussi à obtenir une déconnexion de la console et quand elle tombe en panne, non seulement le propriétaire * est indéfini mais helperName est également indéfini. Il manque donc plus d'une chose.

@workmanw Quelques étapes qui m'ont aidé à faire

• Exécutez votre application localement avec la CLI, modifiez bower_components / ember / ember.prod.js
• Ajoutez les journaux de console avant hasRegistration et après, comme ceci:

if (validateLazyHelperName(name, owner, env.hooks.keywords)) {
        var helperName = 'helper:' + name;
        console.log("Before", helperName, owner !== undefined, owner._lookupFactory !== undefined);
        if (owner.hasRegistration(helperName, options)) {
          console.log("After", helperName, owner !== undefined);
          console.log("After _lookupFactory", owner._lookupFactory !== undefined);
          helper = owner._lookupFactory(helperName, options);
        }
      }

Exécutez ember s --prod
Le résultat de ceci pour moi est le suivant, quand il plante:

Before helper:t true true
After undefined false
TypeError: Cannot read property '_lookupFactory' of undefined

Lorsque le second journal de la console s'exécute, helperName et owner sont déjà "indéfinis" et il se bloque évidemment sur "After _lookupFactory" console.log.

Edit: Gardez à l'esprit cette aide: t est fait sur mesure pas à partir de ember-i18n.

Désolé d'avoir attribué +1 à ce contenu, mais je ne sais pas si je suis abonné aux mises à jour avec juste une émoticône "pouce levé".

Exactement la même erreur, uniquement dans les versions de production.

Chrome: 48.0.2564.116, 49.0.2623.87
MacOS: 10.9.5

@stefanpenner avec --nouse_inlining cela ne semble pas se produire. J'ai essayé de courir avec et sans nouse_inlining plusieurs fois et cela ne s'est jamais écrasé lorsque l'inlining était désactivé. Exécuter Chrome sans indicateurs, je pourrais obtenir 5 recharges sur 7 pour planter avec ces console.logs en place à partir de mon commentaire précédent. Je dois encore trouver comment rendre cela reproductible sur Twiddle ou une application de démonstration.

Je vois cela depuis début février (2.3, puis 2.4), OSX et Windows, Chrome uniquement. La suppression de tous les Em.Helper.helpers et ember-truth-helpers personnalisés a empêché les erreurs d'apparaître (bien sûr).

Cela fait un moment que je suis tombé sur un bug qui m'a fait brosser mon chapeau en papier d'aluminium.
_Tu n'es pas seul. La vérité est là-bas._

Voir également cela dans les journaux d'erreurs pour EmberObserver.com. Chiming in car cela pourrait être utile car il est open source https://github.com/emberobserver/client

Egalement sur Ember 2.4.1, visible sur chaque route de l'application, sur Chrome ou Chromium 48 sous Windows 7, 8.1, 10, OS X et Ubuntu.

@typeoneerror fwiw Je suis personnellement très heureux que des gens signalent qu'ils rencontrent le même bogue tout en fournissant des détails sur l'environnement.

Je ne sais pas exactement qui est censé être blessé par de tels rapports: wink:

Je viens d'ouvrir un bug V8, https://bugs.chromium.org/p/v8/issues/detail?id=4839.

Désolé, je n'ai toujours pas eu de cycles pour approfondir, espérons-le bientôt.

C'était plus difficile à reproduire pour moi que ce qui a été décrit mais j'ai pu reproduire sur une version très récente de Mac OS Chromium version 51.0.2671.4 (64 bits)

Je viens de voir cela se produire sur un Twiddle avec une version ember.prod.js. Chrome 49.0.2623.87 (64 bits), OS X 10.11.3

Uncaught TypeError: Cannot read property '_lookupFactory' of undefined VM3158 ember.prod.js:11783

La reproduction n'est toujours pas claire, une fois que j'aurai les étapes de reproduction, je partagerai le Twiddle ici.

@raido Il peut être utile d'exécuter Chrome avec --js-flags = "- prévisible", ce qui désactive diverses fonctionnalités connues pour provoquer l'indéterminisme (comme tout ce qui implique des threads d'arrière-plan). S'il vous plaît faites-moi savoir quand vous trouverez un bon repro!

: tada: Ouais! Je peux voir dans nos journaux une demi-douzaine de personnes ont pu le reproduire sur différentes versions de chrome, dont 51.

@krisselden Je suis désolé pour ça. Je pense que dans mes réponses précédentes, j'avais laissé entendre que ce n'était pas toujours reproductible, mais j'aurais dû être explicite à ce sujet sur le commentaire avec les étapes de reproduction. Parfois, cela ne semble tout simplement pas arriver. Il y a encore des variables en jeu ici que je ne saisis pas complètement. Si je n'arrive pas à faire en sorte que cela se produise facilement après 2 ou 3 tentatives, le redémarrage de Chrome peut aider.

@stefanpenner J'ai quelques cycles maintenant et j'ai passé 6-8 heures à essayer de le reproduire en un tour de main. Si vous avez des idées ou des intuitions, je serais heureux de les explorer. Je n'ai tout simplement pas assez de connaissances du domaine sur ce problème.

@workmanw @stefanpenner J'ai le même problème avec la connaissance de tout le problème qui se passe ici. Mon twiddle qui plantait souvent, le fait maintenant rarement et je n'ai rien changé à part fermé et ouvert Chrome plusieurs fois (probablement sans rapport). C'est vraiment ennuyeux.

@jakobkummerow Je n'ai pas pu planter mon application avec le drapeau --predictable.

J'ai essayé de créer un test d'acceptation échouant ici: https://github.com/runspired/bug-13071

bower_components est engagé puisque ember.debug.js a été échangé contre ember.prod.js . Pas de chance pour l'instant de reproduire, mais je suis sur Chrome 47 qui n'est apparu ci-dessus dans aucun rapport de bogue.

@runspired J'ai essayé cela aussi avec un Twiddle, il ne s'est jamais écrasé pendant les tests, mais parfois après avoir terminé les tests et naviguer manuellement autour de lui le ferait.

Le Twiddle avec lequel j'ai joué avec https://ember-twiddle.com/7fdf923d89ea37095cf3

Une fois que je l'ai eu, il s'est écrasé trois fois de suite, comme chaque transition s'est terminée par un message _lookupFactory.

Edit: J'ai réussi à attraper des stackstraces de 3 crashs du Twiddle sur screencast, 2 d'entre eux sont identiques, l'un est différent. https://www.dropbox.com/s/51uwx6zo1scs7il/bug-13071.mp4?dl=1

Il est trop difficile pour moi de reproduire ce problème de manière fiable, mais mon suspect actuel est celui-ci https://github.com/emberjs/ember.js/blob/cfed40154285501c19a60aef3c0f51c645c9d44d/packages/ember-runtime/lib/mixins/container_Lproxy.js -L119 si quelqu'un a plus de facilité à reproduire, j'écrirais les alias à la main et je ne fermerais pas non plus la cible du proxy.

@workmanw si je fais un PR pour éviter ce que je pense être le problème, pouvez-vous le tester?

Je viens également de frapper cela pour la première fois en production (et je me souviens avoir vu cette discussion sur Twitter). Chrome 48.0.2564.116 et Ember 2.3.

J'ai discuté avec @krisselden sur Slack. Oui, je serais heureux d'essayer un PR. Mon taux de reproduction est d'environ 33% du temps (donc assez fréquemment).

@workmanw vous pouvez essayer ce qui précède en clonant le curl https://github.com/emberjs/ember.js/pull/13116.patch | git am et en faisant npm run build et en utilisant dist comme votre bower_components / ember

@krisselden Malheureusement, cela ne semble pas faire de différence :(

J'ai vérifié v2.4.2 , appliqué le correctif et fait une compilation. Copié ember.min.js dans mon app/bower_components/ember/ember.debug.js . Suppression du répertoire tmp/ et démarrage du serveur. J'ai confirmé que le correctif avait été appliqué en regardant l'onglet sources.

Au cas où quelqu'un voudrait vérifier, voici le hachage après mon patch et build: MD5 (dist/ember.min.js) = 23ab1021bebdf170d21338fecf347937

Heureux de continuer à essayer des idées que vous pourriez avoir.

@workmanw basé sur le dernier commentaire sur https://bugs.chromium.org/p/v8/issues/detail?id=4839#c7 et en regardant le code, utilisez-vous la recherche d'assistance locale? Je suppose que _findHelper est inséré ici https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/lib/system/lookup-helper.js#L62 quand il n'a jamais vu ce cas être vrai et quand vous naviguez vers une route où il devient vrai hasRegistration le code incorporé n'a pas de propriétaire pour le deopt.

Ma pensée actuelle est https://github.com/emberjs/ember.js/commit/8af7da67c4b1eab94a6adfc82c91af98dc3ee532 déclenche le bogue dans la v8 et qu'empêcher _findHelper d'insérer ou de réchauffer la branche avec un assistant local le résoudrait jusqu'à ce que le bogue soit corrigé dans v8.

@krisselden Si vous avez quelque chose de prêt à être testé, je peux l'essayer. Mon taux de reproduction est à peu près le même que celui de @workmanw .

@workmanw Pouvez-vous tester le PR que j'ai réalisé sur la base du commentaire https://bugs.chromium.org/p/v8/issues/detail?id=4839#c9 ?

PR https://github.com/emberjs/ember.js/pull/13118

Avec ce changement, je n'ai pas pu planter mon application. Si j'annule les modifications, il commence à planter presque instantanément.

: confetti_ball:: tada: J'ai testé le PR de @raido et je ne peux pas reproduire le problème. Cela ne semble pas être une solution réussie. :sourire:

Edit: testé avec Chrome 49 et Chrome 51.

J'ai essayé de suivre de près les scénarios rapportés, mais je pense que ce code est également dans Ember 2.3. Ember 2.3 souffre-t-il également de ce problème?

Oui, je peux confirmer qu'Ember v2.3 est également affecté par cela.

OK, extrait https://github.com/emberjs/ember.js/issues/13118 dans les branches beta, release et release-2-3. La version et les canaux bêta devraient bientôt recevoir de nouvelles versions (via Travis) s'il vous plaît cliquez dessus pendant un moment afin que nous puissions confirmer qu'il corrige effectivement ce problème ...

@workmanw @raido Merci beaucoup d'avoir passé autant de temps à reproduire le bogue, à travailler avec Chromium pour trouver et résoudre ce problème.
C'est l'un de ces Heisenbugs où, en essayant d'être un utilisateur OSS responsable, j'ai attendu pour déposer un problème pendant plus d'un mois parce que je ne pouvais pas créer un fichier gist / twiddle / bin / etc stable. Cela a défié tellement la logique que j'ai pensé que c'était de ma faute. La prochaine fois, je serai plus proactif et enverrai un ping à la salle Slack pour les autres victimes.

Bon travail à tous!

@ 2468ben je me demande si nous devrions peut-être avoir un label hesienbug / peut-être vmbug?

[corrigé par # 13118]

:)

@rwjblue J'ai mis à jour mon bower.json maintenant pour utiliser "ember": "components/ember#9c3e5820" et je vais l'envoyer à travers le cycle d'assurance qualité. Je vous ferai savoir si des problèmes surgissent.

Merci beaucoup!

Nous avons également rencontré ce problème et cela semble l'avoir résolu. Je martèle notre site contre la version ember#9c3e5820 depuis plus d'une heure maintenant et je n'ai vu aucun problème.

v2.4.3 a été publié avec le travail autour ajouté dans https://github.com/emberjs/ember.js/pull/13118.

Oh mec, les heures que j'ai passées à essayer de reproduire / corriger ce bug avant de trouver ce fil ... euh. Bon travail les gars!

nous exécutons actuellement une application sur [email protected] et nous rencontrons ce problème exact selon Sentry même si le code inclut la solution de contournement dans https://github.com/emberjs/ember.js/pull/13118 😞

@ Turbo87 Ce problème a également été

Êtes-vous sûr que c'est le même problème?

@workmanw ouais, à peu près sûr que c'est la même chose. apparemment, certains de nos utilisateurs utilisent encore d'anciennes versions de Chrome et en fait certains navigateurs dérivés (Sogou Explorer, Opera, Chromium, Dragon) montrent un comportement similaire selon nos journaux Sentry

:(. Je ressens votre douleur. Certains de nos clients sont des entreprises qui bloquent les utilisateurs dans des versions spécifiques de Chrome et ne les laissent jamais mettre à jour.

Il est possible que ce problème refait surface d'une manière ou d'une autre. Je peux dire avec certitude à 100% qu'à l'époque, cette solution de contournement a résolu le problème pour nous ( v2.4.3 ).

Pareil ici.

@ Turbo87 avez-vous des versions spécifiques?

• Chrome 49.0.2623
• Opera 36.0.2130
• Chrome 48.0.2564
• Sogou Explorer 1.0
• Chrome 48.0.2564
• Chrome 50.0.2632

Chrome 49 est de loin le plus courant pour une raison quelconque

@ Turbo87 avez-vous déjà trouvé un moyen de contourner ce problème?

@givanse nous avons mis à niveau vers Ember 2.12 maintenant et ne semble plus avoir ce problème