Rastreando o excesso de pilha em fibra de meteor/nó

Question

Estou vendo esse acidente agora e não estou familiarizado o suficiente com a infraestrutura de fibra de nó para saber por onde começar a interpretar o erro ou instrumentar o código ...

Meteor server running on: http://localhost:3000/
W202407-10:06:05.740(-8)? (STDERR) /Users/dauser/.meteor/tools/0b2f28e18b/lib/node_modules/fibers/future.js:173
W202407-10:06:07.363(-8)? (STDERR)                      throw(ex);
W202407-10:06:07.363(-8)? (STDERR)                            ^
W202407-10:06:07.363(-8)? (STDERR) RangeError: Maximum call stack size exceeded
=> Exited with code: 8
=> Meteor server restarted

Pelo que entendi, algo está recorrente um pouco com entusiasmo, a pilha do servidor explode e trava. Infelizmente, não tenho nenhuma idéia de onde está essa função ofensiva-olhei para a chamada My DePs.autorun (apenas uma no momento) e não parece ser o problema. Nenhum do meu código é implementado com recursão explícita, e não tenho nenhum motivo para suspeitar que objetos grandes estão sendo transmitidos. Obviamente, não tenho muita certeza, é claro.

Estou realmente procurando conselhos sobre como instrumentar o código para me mostrar onde as coisas estão ficando fora de controle. Como o Meteor está fazendo muito nos bastidores, seria realmente útil se alguém pudesse me dar algumas dicas sobre onde procurar.

Apenas voltando a isso, e ainda estou bastante perdido quanto a onde estar olhando. isto A atualização sugerida para o nó 0.11.x me daria mais informações, mas isso parece não ter adicionado mais detalhes quando travar.

O acidente acontece após qualquer interação da página-ou seja, o servidor é iniciado e está funcionando bem, mas se eu recarregar o navegador ou interagir com a própria página, Boom!

Pela demanda popular, aqui está o código do servidor:

isAuthorized = () ->
    console.log "checking authorization"
    this.userId == Assets.getText('authorizedUsers')

Meteor.methods(
    isAuthorized : isAuthorized
    filePickerKey : () -> 
        # TODO: properly abstract this, rather than copy/paste...       
        if this.userId == Assets.getText('authorizedUsers')
            Assets.getText('fpKey')
        else
            Meteor.Error 403, 'Error 403: Forbidden')

Linha 172 de Future.js não forneceu mais detalhes:

I2041-15:52:07.363(-8)? Resolve cb threw Maximum call stack size exceeded

E aqui está o problema em que tento enquanto tento usar o inspetor de nó. Eu tenho jogado com isso há meia hora, então provavelmente estou apenas cometendo algum erro fundamental, mas: instalei o inspetor do nó via NPM (NPM Install -g Node-Inspetor).

Então eu tento

$ node-inspector &
[1] 3408
$ Node Inspector v0.6.2
  info  - socket.io started
Visit http://127.0.0.1:8080/debug?port=5858 to start debugging.

$ meteor &
[2] 3413
$ [[[[[ ~/Projects/indefinite-ways ]]]]]

=> Meteor server running on: http://localhost:3000/

$ kill -s USR1 3413
Hit SIGUSR1 - starting debugger agent.
debugger listening on port 5858

até agora tudo bem. Neste ponto, o lado do cliente não está aberto no meu navegador (ou seja, sem guia apontando para localhost: 3000). Abro uma guia Chrome apontando para localhost: 5858 e veja a fonte para meteor.js, defina um ponto de interrupção na linha 6 de meteor.js

var Fiber = require('fibers');

e depois abra a guia Cliente do Meteor (localhost: 3000) e o transbordamento de pilha acima mencionado aparece novamente. O depurador não interrompe na linha 6 ou, de qualquer outra maneira, indica que notou. O mesmo acontece se eu definir um ponto de interrupção na linha 3.

Answer 1

A resposta um pouco mais útil vem do FAQ de meteoros não oficiais:

$ node-inspector &
$ NODE_OPTIONS='--debug-brk' mrt run &

Isso inicia o processo de inspetor de nó em segundo plano e, em seguida, inicia o contêiner do nó do meteoro, ouvindo o conjunto de sinalizadores de depuração correta. Abrindo a guia Chrome para http://127.0.0.1:8080/debug?port=5858 Deixe -me passar.

Também não estritamente A resposta para a pergunta, mas a linha ofensiva no código acima parece estar ligando Meteor.Error no código do servidor. Ainda vou aceitar com prazer uma resposta para isso que teria identificado isso. Suponho que o meteor.error não seja de todo ejsonable e, ao tentar analisá -lo, a pilha explode.

Answer 2

Tentar Node-Inspetor, permite inspecionar a pilha de chamadas. Isto é um Apresentação em vídeo De como usá -lo, visualmente parece o depurador Chrome (é a mesma fonte base).

Answer 3

Linha 173 de Future.js encaminha uma exceção para o próximo ouvinte. Parece que, no seu caso, o próximo ouvinte é a própria instância, resultando em um loop de batida de pilha.

Edite seu arquivo Future.js (caminho referenciado no OP) e descomentar a linha do console.log logo acima dele ... então você deve ver uma explicação mais detalhada do que está acontecendo. Se a saída do console.log não for útil para resolver, poste aqui para mais diagnósticos.

Meu palpite é que está relacionado a um pacote ausente, por este tópico.