Seguimiento del desbordamiento de la pila en fibra de meteorito/nodo

Question

Estoy viendo este bloqueo ahora y no estoy lo suficientemente familiarizado con la infraestructura de fibra de nodo para saber dónde comenzar a interpretar el error o instrumentar el 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

Según tengo entendido, algo recurre demasiado con entusiasmo, la pila de servidor explota y se bloquea. Desafortunadamente, no tengo una idea real de dónde está esta función ofensiva: miré a mis dep. Ninguno de mi código se implementa con recursión explícita, y no tengo ninguna razón para sospechar que se están pasando objetos grandes. Obviamente, no estoy realmente seguro, por supuesto.

Realmente solo estoy buscando consejos sobre cómo instrumentar el código para mostrarme a dónde se están saliendo de control las cosas. Dado que Meteor está haciendo mucho detrás de escena, sería realmente útil si alguien pudiera darme algunos consejos sobre dónde mirar.

Solo vuelve a esto, y todavía estoy bastante perdido en cuanto a dónde estar mirando. este La actualización sugerida al nodo 0.11.x me daría más información, pero hacer eso no parece haber agregado más detalles cuando se bloquea.

El bloqueo ocurre después de cualquier interacción de página, es decir, el servidor se inicia y funciona bien, pero si recargo en el navegador o interactúo con la página en sí, ¡BOOM!

Por demanda popular, aquí está el código del 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')

Línea incommedia 172 de Future.js no proporcionó más detalles:

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

Y, aquí está el problema con el que me encuentro mientras intento usar Node-Inspector. He estado jugando con esto durante la última media hora, por lo que es probable que solo comete un error fundamental, pero: instalé el inspector de nodos a través de NPM (NPM Install -G Node-Inspector).

Entonces, lo intento

$ 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

Hasta ahora, todo bien. En este punto, el lado del cliente no está abierto en mi navegador (es decir, ninguna pestaña apunta a Localhost: 3000). Abro una pestaña Chrome que apunta a localhost: 5858, y consulte la fuente de meteor.js, establecí un punto de interrupción en la línea 6 de meteor.js

var Fiber = require('fibers');

y luego abra la pestaña Cliente de meteoritos (localhost: 3000) y el desbordamiento de la pila mencionado anteriormente vuelve a aparecer. El depurador no se detiene en la línea 6, o de ninguna otra manera indica que se ha dado cuenta. Lo mismo ocurre si establece un punto de interrupción en la línea 3.

Answer 1

La respuesta un poco más útil proviene del Preguntas frecuentes de meteoritos no oficiales:

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

Esto inicia el proceso de nodo-inspector en segundo plano, y luego inicia el contenedor de nodo de Meteor escuchando con el conjunto de indicadores de depuración correctos. Abrir la pestaña Chrome a http://127.0.0.1:8080/debug?port=5858 Déjame atravesar.

Tampoco estrictamente La respuesta a la pregunta, pero la línea ofensiva en el código anterior parece estar llamando Meteor.Error en el código del servidor. Con mucho gusto aceptaré una respuesta a esto que hubiera identificado eso. Supongo que Meteor.Error no es en absoluto eJsonable, y al intentar analizarlo, explota la pila.

Answer 2

Probar nodo, permite inspeccionar el CallStack. Esto es un presentación de video De cómo usarlo, visualmente parece el depurador Chrome (es la misma fuente base).

Answer 3

Línea 173 de Future.js Reenvía una excepción hacia el próximo oyente. En su caso, el próximo oyente es la instancia en sí, lo que resulta en un bucle de bloqueo de pila.

Edite su archivo Future.js (ruta referenciada en OP) y descomense la línea console.log justo encima de él ... entonces debería ver una explicación más detallada de lo que está sucediendo. Si la salida de console.log no es útil para resolver, publique aquí para obtener más diagnósticos.

Supongo que está relacionado con un paquete que falta, por este hilo.