Ember.js: Erro após atualizar para o Ember 2.4

O que é ainda mais estranho é que você pode ver na última imagem, há var s = "helper:" + e; na linha 8786 ... mas de alguma forma na linha seguinte s é indefinido. : confused: É quase como se a pilha estivesse sendo obstruída ... ou o depurador do Chrome estivesse apenas errando.

Eu também vi algo assim. Acontece raramente e não sei reproduzir. Também não tenho certeza se é problema do meu aplicativo ou outra coisa.

@raido é sua pilha igual à minha (ou seja, a falha está em _lookupFactory )? Você está no Ember 2.4.1? Você já viu esse problema nas versões anteriores do Ember?

Atualizamos do Ember 2.2 => Ember 2.4 e começamos a ver esse problema pesadamente em nossos logs de servidor em alguns dias.

: +1: vi isso sozinho e me confundi profundamente, a partir de meus logs do 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    }

Como você disse, como owner ser undefined na linha 11782 se passou de owner.hasRegistration a linha antes?

Da mesma forma, só o vi na produção quando reduzido (acima vem dos mapas de origem).

Logs mostram que só vimos isso no Chrome até agora.

@workmanw Sim, meu erro também está relacionado a _lookupFactory e é ver lookupHelper no stacktrace.

Logs da construção de produção, aconteceu agora mesmo com a 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)

Posso confirmar esse problema no 2.4.2, vendo-o às vezes em produção, mas ainda não em desenvolvimento. Isso pode ser causado pelo inspetor de brasa, talvez?

Para mais informações: nunca tive isso no 2.3.xe a pilha é a mesma (_lookupFactory)

EDITAR: Posso confirmar que este não é um problema com o inspetor de brasa, ocorreu um erro enquanto o inspetor estava desativado.

Bug confirmado em 2.4.1 e 2.4.2. Acontece apenas com js minimizado

@jcbvm @ gdub22 Algum de vocês conseguiu reproduzi-lo de forma consistente? Tentei e tentei encontrar pelo menos um conjunto consistente de etapas em nosso aplicativo com a esperança de construir um enigma de brasa, mas não tive sorte.

Isso é completamente anedótico e provavelmente uma pista falsa, mas parece acontecer ao tentar renderizar um auxiliar que possui um componente ancestral renderizado com o auxiliar de componente ( {{component componentName}} ).

@workmanw Da mesma forma que não conseguimos reproduzir de forma consistente, usamos muito o auxiliar {{component}} todo o nosso aplicativo.

@workmanw não é 100% consistente, mas acho que reduzi a um componente específico que usa o auxiliar de componente em seu próprio modelo.

O Uglify transpila a função acima para:

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;
}

Observe que ambos os acessos de propriedade em owner foram compilados em uma única linha. Meu palpite é que o travamento realmente acontece no primeiro, e a fidelidade do mapa de origem não é alta o suficiente para distingui-los corretamente.

Editado para adicionar: Ah, mas a falha é definitivamente para _lookupFactory property , então minha especulação deve estar errada. Curioso e curioso.

@ ef4 Talvez ... mas nas poucas vezes em que o (em seu snippet) é indefinido, mas r.owner é um proprietário válido. Na verdade, sou capaz de fazer r.owner.hasRegistration(s,n) && (r.owner._lookupFactory(s,n)); e obter a aula. Concedido, isso ocorre após o Chrome ter quebrado em uma exceção detectada ... então, o depurador também pode estar em um estado enganoso.

@ ef4 sim, é definitivamente estranho.

O V8 poderia estar otimizando-o por algum motivo? Quem sabe mais sobre as artes negras do V8, talvez @stefanpenner ?

Se o código de linha que está travando for:

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

então:

1. o.hasRegistration(s,n) já retornou um valor verdadeiro; isso significa
2. o não é nem null nem undefined ; Portanto
3. Cannot read property '_lookupFactory' of undefined está errado ou é um bug na v8

Estou perdendo algo óbvio?

Para as pessoas que reproduziram esse problema, qual versão do Chrome você está executando? Você o reproduziu no Firefox, IE ou Safari?

@wycats Não vejo nada óbvio que você esteja perdendo. Estas são as mesmas conclusões a que cheguei. Só vimos esse problema conectado ao Chrome mais recentemente (48). Em meu teste de reprodução, usei 48.0.2564.116. Eu, pessoalmente, não experimentei Firefox, IE ou Safari, mas vou experimentá-los e apresentar um relatório.

EDIT: Não consigo simplificar o problema a ponto de produzir um enigma. Mas se for útil, posso enfileirar uma ou mais falhas pausadas em um ponto de interrupção e pular em um herói de tela se alguém quiser vasculhar o depurador do Chrome. Às vezes consigo reproduzi-lo 3 vezes em um minuto. Às vezes, leva 20 minutos ou mais.

@wycats Tudo bem. Passei a última hora testando o Chrome, Safari e Firefox. Consegui reproduzi-lo várias vezes no Chrome e nunca no Safari e Firefox. Não tenho certeza se isso é conclusivo, mas certamente aponta cada vez mais para um problema específico do Chrome.

Tudo isso me lembra http://yehudakatz.com/2010/01/02/the-craziest-fing-bug-ive-ever-seen/

Eu também não fui capaz de reproduzi-lo. Para mim, isso normalmente acontece quando o aplicativo é inicializado. Recarregar o aplicativo várias vezes provavelmente travá-lo, mas não é consistente. Ele pode travar 5 vezes em apenas alguns minutos ou levar meia hora. Eu testei no Chrome mais recente.

@workmanw Eu recomendaria forçar essa função a permanecer em modos específicos, isso pode nos ajudar a descobrir mais sobre o problema. Nesse ponto, também devemos executar ping em nossos amigos v8. Mas para isso, uma reprodução (mesmo um aplicativo completo) provavelmente será necessária.

Para manter as funções em modos específicos, você pode desabilitar lentamente partes do v8 e ver se o bug para. Isso nos ajudará a chegar mais perto da causa raiz.

primeiro, eu desativaria o inlining, executando o chromes v8 com ele desativado: --nouse_inlining (meu palpite é que isso pode ser suficiente)

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

Por outro lado, tente desativar o virabrequim totalmente --crankshaft=false

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

@stefanpenner

Eu testei isso usando o Chrome 48 (em vez de canário). Se você quiser que eu experimente com Canary, ficarei feliz em.

Com --nouse_inlining não consegui reproduzir este problema.
Com --crankshaft=false eu era capaz de reproduzir este problema.

Nesse ponto, também devemos executar ping em nossos amigos v8. Mas para isso, uma reprodução (mesmo um aplicativo completo) provavelmente será necessária.

Eu entendo completamente. Passei cerca de 4 horas tentando "trabalhar para a frente" e construir um Ember-twiddle que reproduzisse isso. Eu simplesmente não entendo o suficiente do que está acontecendo para fazer isso. Portanto, agora vou começar a "trabalhar para trás" usando nosso aplicativo para simplificar a reprodução, reduzindo as etapas de reprodução e retirando o máximo possível de nosso aplicativo.

Com --nouse_inlining, não consegui reproduzir esse problema.

parece esperado, então provavelmente está relacionado a algum tipo de bug in-line.

Com --crankshaft = false, consegui reproduzir esse problema.

esta pode ser a bandeira errada, não me lembro.

Eu entendo completamente. Passei cerca de 4 horas tentando "trabalhar para a frente" e construir um Ember-twiddle que reproduzisse isso. Eu simplesmente não entendo o suficiente do que está acontecendo para fazer isso. Portanto, agora vou começar a "trabalhar para trás" usando nosso aplicativo para simplificar a reprodução, reduzindo as etapas de reprodução e retirando o máximo possível de nosso aplicativo.

@workmanw, é possível compartilhar o aplicativo (ou um URL para o aplicativo) no estado em que se encontra com as etapas de reprodução?
A realidade é que reproduzir isso isoladamente pode ser complicado.

R: sadpanda: solução alternativa, é forçar a função a exceder o AST máximo que pode ser embutido. Isso deve permitir que você: envie:

colocar a seguinte string no corpo dessa função deve resolver o problema (agora, esses limites / heurísticas mudam com o tempo)

"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 se você também puder fazer o check-in no canário, isso seria útil.

@stefanpenner

colocar a seguinte string nessa função deve resolver o problema (agora, eles podem mudar com o tempo)

Seu conhecimento dos internos nunca deixa de me surpreender.

@workmanw, é possível compartilhar o aplicativo como está com etapas para reproduzi-lo?

Sim, devo ser capaz de fazer isso acontecer. Se você me der um pouco, provisionarei algumas credenciais para um de nossos ambientes de pré-produção e prepararei os dados. Eu provavelmente poderia compartilhar a fonte se necessário, mas teria que fazer isso em particular.

@workmanw se você também puder fazer o check-in no canário, isso seria útil.

Feito. Verifiquei o canário "versão 51.0.2673.0 canário (64 bits)" sem nenhuma das sinalizações e, infelizmente, ainda consegui reproduzi-lo.

Eu provavelmente poderia compartilhar a fonte se necessário, mas teria que fazer isso em particular.

Isso me ajudaria pessoalmente a tentar reduzir ainda mais o problema, embora sem garantias. Eu mais ou menos adoraria fazer o seguinte:

• prepare uma reprodução para o pessoal do V8
• explorar soluções provisórias [BUGFIX]
• obter um relatório V8 em (hoje / neste fim de semana)

Com um aplicativo na minha frente (onde posso alterar o código + explorar), descobrir uma solução alternativa / reprodução adequada pode ser possível.

EDITAR: O aplicativo com link abaixo está usando uma compilação de ember que contém a solução alternativa de PR # 13118. Não é mais válido para a reprodução desta edição. Se alguém estiver interessado em reproduzir este problema usando nosso aplicativo, entre em contato comigo e provavelmente poderei fazer isso acontecer.

@stefanpenner Portanto,

Isso ainda não é 100% reproduzível.

1) Visitando este URL: https://qa-integration.batterii.com/#/community/MTpDb21tdW5pdHksOTAwMQ/room/MTpSb29tLDE5NzQ2MzAwMQ/wall/MTpSb29tLDE5NzQ2MzAwMSxXYWxsLDEwDAxs

2) Login com e-mail: [email protected] e senha: tomster1 . Isso deve conectar você diretamente a uma página semelhante a esta:

3) Depois de fazer login e acessar a página acima, você precisará atualizar (para começar a limpar a partir dessa página).

4) Abra o depurador do Chrome e execute o seguinte no 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) Defina o Chrome Debugger como "Pausar nas exceções detectadas".

6) O código injetado deve ter adicionado um botão no canto superior direito. Clique nesse botão. Primeiro, uma nova aba será aberta e um arquivo será baixado, então uma caixa de diálogo modal deve abrir e fechar várias vezes. Esse modal é realmente "roteável", portanto, você também deve observar a mudança de rota. Na segunda ou terceira abertura do modal, você deve atingir a exceção. Se isso não ocorrer, atualize o navegador e tente novamente (começando com a etapa 4).

Vou trabalhar para obter o código-fonte enquanto isso. Nós rodamos no Google App Engine, então você ainda terá que se conectar a um servidor em nuvem, mas devo ser capaz de providenciar para que você possa executar o aplicativo cliente localmente (proxy para um servidor em nuvem).

Por último, estou de folga agora e estarei até cerca das 16h EST. Eu ficaria feliz em fazer um screenhero, se necessário. Também estarei disponível o dia todo amanhã.

Etapas de reprodução incríveis!

Estou executando tarefas atualmente, mas tentarei investigar mais tarde hoje (ou amanhã de manhã).

@stefanpenner Muito obrigado! Estarei online o dia todo amanhã e feliz em ajudar se necessário. Você pode me encontrar na folga do emberjs. Também enviei um e-mail sobre como obter acesso ao nosso código-fonte (enviei um e-mail com o seu @gmail listado na sua conta do github).

@stefanpenner Para ajustei levemente as etapas. Descobri que é muito mais provável que você reproduza o problema se usar a lista de "modo de alvenaria" do nosso aplicativo. Tudo o que mudou foi o URL na etapa 1, a captura de tela abaixo da etapa 2 e o snippet de código na etapa 4.

_Em resposta à pergunta acima, se este for apenas v8 / Chrome: _ verifique nossos registros, encontrei 8 casos, todos Chrome (49/48) no Windows (7 e 10). Infelizmente não tenho mais pontos de dados.

Tenho tentado reproduzir isso, mas sem sorte no Twiddle e localmente. Mas parece ser específico para helpers, pois tenho outro app em produção sem helpers e não trava, leve isso com sal.

Eu fiz alguns testes de força bruta, forçando o aplicativo a navegar entre as rotas para frente e para trás e às vezes o bug ocorria após 3 transições, jogava o erro e se recuperava com a próxima transição e, após a recuperação, parecia nunca travar novamente.

Edit: Eu deixei ele navegar por 7 rotas por 300 vezes, com atraso de 50ms entre as transições e nada quebraria. Fiz 5 recarregamentos manuais depois disso e travou na inicialização ao fazer a renderização de "rota de índice" inicial onde estão alguns auxiliares em modelos.

Eu fiz alguns testes de força bruta, forçando o aplicativo a navegar entre as rotas para frente e para trás e às vezes o bug ocorria após 3 transições, jogava o erro e se recuperava com a próxima transição e, após a recuperação, parecia nunca travar novamente.

Isso descreve absolutamente minha experiência.

Em nosso caso, usamos window.open para acionar o download de um arquivo e essa ação "parece" ajudar a aumentar a probabilidade de esse problema acontecer (mas pode ser uma pista falsa). Para mim, às vezes eu entro em um rolo e isso vai acontecer 10 em 10 vezes após a 3ª ou 4ª transição. Outras vezes, não acontecerá uma vez em meia hora.

@workmanw Eu tenho um monte de coisas do tipo "provável capuz" que "parecem" ajudar a reproduzi-lo, mas na realidade não fui capaz de seguir nenhuma das "dicas" que o aplicativo me deu. Parece completamente aleatório.

Tentei travar seu aplicativo também pelos passos de reprodução dados aqui, não aconteceu.

@stefanpenner Eu tentei adicionar um pouco de "costeleta de porco" para funcionar o corpo, não parecia ajudar ou fiz algo errado.

De qualquer forma, acho que tenho uma maneira de fazer isso acontecer com mais frequência. Eu agora confirmei que é sempre o mesmo ajudante:que trava no meu aplicativo. Vou continuar cavando.

Até agora, eu consegui obter alguns logs de console e quando ele travou, não apenas o proprietário * é indefinido, mas helperName também é indefinido. Portanto, há mais de uma coisa faltando.

@workmanw Algumas etapas que me ajudaram a fazer meu aplicativo travar muito mais:

• Execute seu aplicativo localmente com CLI, modifique bower_components / ember / ember.prod.js
• Adicione logs de console antes de hasRegistration e depois, como este:

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);
        }
      }

Execute ember s --prod
O resultado disso para mim é o seguinte, quando ele trava:

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

Conforme o segundo log do console é executado, helperName e owner já estão "indefinidos" e obviamente ele trava no console.log "Depois de _lookupFactory".

Edit: Tenha em mente este ajudante: t é feito sob medida, não em ember-i18n.

Desculpe por marcar isto com +1, mas não tenho certeza se eu consigo me inscrever em atualizações com apenas um "emote de polegar para cima".

Exatamente o mesmo erro, apenas em compilações de produção.

Chrome: 48.0.2564.116, 49.0.2623.87
MacOS: 10.9.5

@stefanpenner com --nouse_inlining não parece ocorrer. Tentei executar com e sem nouse_inlining algumas vezes e nunca travou quando o inlining estava desativado. Executando o Chrome sem sinalizadores, eu poderia obter 5 de 7 recarregamentos para travar com os console.logs no lugar do meu comentário anterior. Eu ainda tenho que descobrir como fazer isso reproduzível no Twiddle ou no aplicativo de demonstração.

Tenho visto isso desde o início de fevereiro (2.3, depois 2.4), OSX e Windows, apenas Chrome. A remoção de todos os Em.Helper.helpers e ember-truth-helpers personalizados impediu a exibição de erros (é claro).

Já faz um tempo desde que encontrei um bug que me fez limpar meu chapéu de papel alumínio.
_Você não está sozinho. A verdade está lá fora._

Também vejo isso nos logs de erros do EmberObserver.com. Chiming in porque pode ser útil, pois é de código aberto https://github.com/emberobserver/client

Também no Ember 2.4.1, visto em todas as rotas do aplicativo, no Chrome ou Chromium 48 no Windows 7, 8.1, 10, OS X e Ubuntu.

@typeoneerror fwiw Estou pessoalmente muito feliz em ter pessoas relatando que experimentaram o mesmo bug ao fornecer detalhes do ambiente.

Não tenho certeza de quem exatamente deve ser prejudicado por tais relatórios: wink:

Acabei de abrir um bug V8, https://bugs.chromium.org/p/v8/issues/detail?id=4839.

Desculpe, ainda não tive nenhum ciclo para dar uma olhada mais profunda, espero que em breve.

Foi mais difícil de reproduzir para mim do que o que foi descrito, mas fui capaz de reproduzir em uma versão de compilação do Mac OS Chromium muito recente 51.0.2671.4 (64 bits)

Acabei de ver isso acontecendo em um Twiddle com a compilação 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

Reprodução ainda obscura, uma vez que eu tenha as etapas para reprodução, compartilharei o Twiddle aqui.

@raido Pode ajudar rodar o Chrome com --js-flags = "- previsível", que desativa vários recursos que são conhecidos por causar indeterminismo (como qualquer coisa envolvendo threads em segundo plano). Avise-me quando encontrar um bom representante!

: tada: Yay! Posso ver em nossos registros cerca de meia dúzia de pessoas que conseguiram reproduzir isso em várias versões do Chrome, incluindo 51.

@krisselden , sinto muito por isso. Acho que em minhas respostas anteriores eu havia sugerido que nem sempre era reproduzível, mas deveria ter sido explícito sobre isso no comentário com as etapas de reprodução. Às vezes, simplesmente parece não acontecer. Ainda há variáveis ​​em jogo aqui que não entendo totalmente. Se eu não conseguir fazer isso acontecer facilmente após 2 ou 3 tentativas, reiniciar o Chrome pode ajudar.

@stefanpenner Agora tenho alguns ciclos e passei de 6 a 8 horas tentando reproduzi-los em um twiddle. Se você tiver alguma ideia ou palpite, ficarei feliz em explorá-los. Simplesmente não tenho conhecimento de domínio suficiente sobre este problema.

@workmanw @stefanpenner Tenho o mesmo problema com o conhecimento de todo o problema que está acontecendo aqui. Meu twiddle que costumava travar com frequência, agora acontece raramente e não mudei nada, exceto fechado e aberto o Chrome algumas vezes (provavelmente não relacionado). É realmente irritante.

@jakobkummerow Não consegui travar meu aplicativo com o sinalizador --predictable.

Tenho tentado criar um teste de aceitação com falha aqui: https://github.com/runspired/bug-13071

bower_components está comprometido porque ember.debug.js foi trocado por ember.prod.js . Sem sorte até agora na reprodução, mas estou no Chrome 47 que não apareceu acima em nenhum relatório de bug.

@runspired Eu tentei isso também com um Twiddle, ele nunca travava durante os testes, mas às vezes, depois de concluí-los e navegar manualmente ao redor, travava.

O Twiddle que eu tenho usado https://ember-twiddle.com/7fdf923d89ea37095cf3

Assim que consegui travar três vezes seguidas, como se cada transição terminasse com a mensagem _lookupFactory.

Edit: Consegui pegar stackstraces de 3 travamentos do Twiddle no screencast, 2 deles são iguais, um é diferente. https://www.dropbox.com/s/51uwx6zo1scs7il/bug-13071.mp4?dl=1

É muito difícil para mim reproduzir esse problema de forma confiável, mas meu suspeito atual é https://github.com/emberjs/ember.js/blob/cfed40154285501c19a60aef3c0f51c645c9d44d/packages/ember-runtime/lib/mixins/container_proxy.js#L115 -L119 se alguém tiver mais facilidade para reproduzir, eu escreveria manualmente os aliases e também não fecharia para o destino do proxy.

@workmanw se eu fizer uma RP para evitar o que eu acho que é o problema, você pode testá-lo?

Eu também acertei isso pela primeira vez na produção (e aconteceu de me lembrar de ter visto essa discussão no Twitter). Chrome 48.0.2564.116 e Ember 2.3.

Conversou com @krisselden no Slack. Sim, ficaria feliz em tentar um PR. Minha taxa de reprodução é de cerca de 33% do tempo (com bastante frequência).

@workmanw você pode experimentar o acima, clonando o curl https://github.com/emberjs/ember.js/pull/13116.patch | git am e npm run build e usando dist como seu bower_components / ember

@krisselden Infelizmente, isso não pareceu fazer diferença :(

Eu verifiquei v2.4.2 , apliquei o patch e fiz uma compilação. Copiou ember.min.js para meu app/bower_components/ember/ember.debug.js . Removido o diretório tmp/ e inicializado o servidor. Confirmei que o patch foi aplicado olhando a guia de fontes.

Caso alguém queira verificar, aqui está o hash após meu patch e compilação: MD5 (dist/ember.min.js) = 23ab1021bebdf170d21338fecf347937

Fico feliz em continuar tentando ideias que você possa ter.

@workmanw com base no último comentário em https://bugs.chromium.org/p/v8/issues/detail?id=4839#c7 e olhando para o código, você está usando a pesquisa de auxiliar local? Suponho que _findHelper está sendo embutido aqui https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/lib/system/lookup-helper.js#L62 quando nunca viu este caso ser verdadeiro e quando você navega para uma rota onde se torna verdadeiro hasRegistration o código embutido não tem dono para o deopt.

Meu pensamento atual é https://github.com/emberjs/ember.js/commit/8af7da67c4b1eab94a6adfc82c91af98dc3ee532 está acionando o bug na v8 e que impedir _findHelper de inlining ou aquecer o branch com um ajudante local resolveria o problema até que o bug fosse corrigido em v8.

@krisselden Se você tiver algo pronto para testar, posso experimentar. Minha taxa de reprodução é quase a mesma de @workmanw .

@workmanw Você pode testar o PR que fiz com base em https://bugs.chromium.org/p/v8/issues/detail?id=4839#c9 comentário?

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

Com essa mudança, não consegui travar meu aplicativo. Se eu reverter as alterações, ele quase instantaneamente começa a travar.

: confetti_ball:: tada: Testei o PR do parece ser uma solução bem sucedida. :sorriso:

Editar: Testado com Chrome 49 e Chrome 51.

Tenho tentado acompanhar de perto os cenários relatados, mas acredito que esse código também esteja no Ember 2.3. O Ember 2.3 também sofre desse problema?

Sim, posso confirmar que o Ember v2.3 também é afetado por isso.

OK, puxei https://github.com/emberjs/ember.js/issues/13118 para os branches beta, release e release-2-3. Os canais de lançamento e beta devem receber novas compilações em breve (via Travis), por favor, bata um pouco para que possamos confirmar que realmente corrige isso ...

@workmanw @raido Muito obrigado por gastar tanto tempo reproduzindo o bug, trabalhando com o Chromium para encontrar e corrigir esse problema.
É um daqueles Heisenbugs em que, tentando ser um usuário OSS responsável, esperei para registrar um problema por mais de um mês porque não consegui criar um gist / twiddle / bin / etc estável. Simplesmente desafiava tanta lógica que percebi que devia ser minha culpa. Da próxima vez, serei mais proativo e executarei um ping na sala do Slack para outras vítimas.

Bom trabalho!

@ 2468ben, gostaria de saber se talvez devêssemos ter um rótulo hesienbug / Maybe vmbug?

[corrigido por # 13118]

:)

@rwjblue Eu atualizei meu bower.json agora para usar "ember": "components/ember#9c3e5820" e vou enviá-lo através do ciclo de controle de qualidade. Eu avisarei você se houver algum problema.

Muito obrigado!

Também estamos enfrentando esse problema e parece que isso o corrigiu. Tenho martelado nosso site contra a construção de ember#9c3e5820 por mais de uma hora e não vi nenhum problema.

A v2.4.3 foi lançada com a solução alternativa adicionada em https://github.com/emberjs/ember.js/pull/13118.

Oh cara, as horas que passei tentando reproduzir / corrigir esse bug antes de encontrar este tópico ... ugh. Bom trabalho pessoal!

no momento, estamos executando um aplicativo em [email protected] e estamos enfrentando exatamente esse problema de acordo com o Sentry, embora o código inclua a solução alternativa em https://github.com/emberjs/ember.js/pull/13118 😞

@ Turbo87 Este problema também foi corrigido no Chrome. Portanto, deve haver apenas 1 ou 2 versões do Chrome que podem funcionar para isso.

Tem certeza de que é o mesmo problema?

@workmanw sim, tenho certeza que é o mesmo. aparentemente, alguns de nossos usuários ainda estão executando versões antigas do Chrome e, de fato, alguns navegadores derivados (Sogou Explorer, Opera, Chromium, Dragon) estão apresentando comportamento semelhante de acordo com nossos registros do Sentry

:(. Eu sinto sua dor. Alguns de nossos clientes são empresas que bloqueiam os usuários em versões específicas do Chrome e nunca permitem que eles atualizem.

É possível que esse problema tenha ressurgido de alguma forma. Posso dizer com 100% de certeza que, na época, essa solução alternativa resolveu o problema para nós ( v2.4.3 ).

O mesmo aqui.

@ Turbo87 você tem versões específicas?

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

Chrome 49 é de longe o mais comum por algum motivo

@ Turbo87 , você já encontrou uma maneira de contornar esse problema?

@givanse, nós atualizamos para o Ember 2.12 agora e não parece ter mais esse problema