Tracciamento del trabocco di stack in fibra meteora/nodo

Question

Sto vedendo questo incidente ora e non ho abbastanza familiarità con l'infrastruttura in fibra del nodo per sapere da dove iniziare a interpretare l'errore o strumentare il codice ...

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

A quanto ho capito, qualcosa è ricorrente un po 'troppo con entusiasmo, lo stack del server esplode e si blocca. Sfortunatamente, non ho una vera idea di dove sia questa funzione offensiva-ho guardato la chiamata my depl.autorun (solo una al momento) e non sembra essere il problema. Nessuno del mio codice è implementato con una ricorsione esplicita e non ho alcun motivo per sospettare che gli oggetti di grandi dimensioni vengano trasmessi. Ovviamente, non ne sono davvero sicuro, ovviamente.

Sto davvero solo cercando consigli su come strumentare il codice per mostrarmi dove le cose stanno sfuggendo di mano. Dal momento che Meteor sta facendo molto dietro le quinte, sarebbe davvero utile se qualcuno potesse darmi alcuni suggerimenti su dove cercare.

Sto solo tornando a questo e sono ancora abbastanza perso su dove cercare. questo L'aggiornamento suggerito al nodo 0.11.x mi darebbe maggiori informazioni, ma farlo non sembra aver aggiunto più dettagli quando si blocca.

L'arresto si avvicina dopo qualsiasi interazione di pagina, ovvero il server si avvia e funziona OK, ma se ricarico nel browser o interagisco con la pagina stessa, boom!

Per domanda popolare, ecco il codice del server:

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')

La riga di non emomobile 172 di Future.js non ha fornito maggiori dettagli:

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

Ed ecco il problema in cui mi imbatto mentre cerco di usare il nodo-ispettore. Ho giocato con questo nelle ultime mezz'ora, quindi probabilmente sto solo facendo qualche errore fondamentale, ma ho installato il nodo-ispettore tramite NPM (NPM Installa -G Node-Inspector).

Quindi, ci provo

$ 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

Fin qui tutto bene. A questo punto, il lato client non è aperto nel mio browser (cioè nessuna scheda che punta a LocalHost: 3000). Apro una scheda Chrome che punta a LocalHost: 5858 e vedo la fonte di Meteor.js I Imposta un punto di interruzione sulla riga 6 di Meteor.js

var Fiber = require('fibers');

e quindi aprire la scheda client meteor (localhost: 3000) e il suddetto overflow dello stack si presenta di nuovo. Il debugger non si ferma sulla riga 6 o in nessun altro modo indica che lo ha notato. Lo stesso è vero se imposto un punto di interruzione alla riga 3.

Answer 1

La risposta leggermente più utile proviene dal FAQ METEOR non ufficiali:

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

Questo avvia il processo di ispettore nodo in background, quindi inizia l'ascolto del contenitore del nodo di Meteor con le giuste flag di debug. Apertura della scheda Chrome a http://127.0.0.1:8080/debug?port=5858 Fammi fare un passo avanti.

Anche no rigorosamente La risposta alla domanda, ma la riga offensiva nel codice sopra sembra chiamare Meteor.Error nel codice del server. Accetterò ancora volentieri una risposta a questo che lo avrebbe identificato. Immagino che meteor.error non sia affatto ejsonabile e nel tentativo di analizzarlo, lo stack esplode.

Answer 2

Provare nodo-ispettore, consente di ispezionare il callstack. Questo è un Presentazione video di come usarlo, visivamente sembra il debugger di Chrome (è la stessa fonte di base).

Answer 3

Riga 173 di Future.js inoltra un'eccezione in seguito al prossimo ascoltatore. Nel tuo caso appare il prossimo ascoltatore è l'istanza stessa, risultando in uno stack che si schianta.

Modifica il tuo file Future.js (percorso a cui si fa riferimento in OP) e il rompicapo la linea Console.log appena sopra ... allora dovresti vedere una spiegazione più dettagliata di ciò che sta accadendo. Se l'output di Console.log non è utile da risolvere, pubblica qui per ulteriori diagnostiche.

La mia ipotesi è che sia correlata a un pacchetto mancante, per questo thread.