Suivi du débordement de la pile en fibre de météore / nœud

Question

Je vois cet accident maintenant et je ne connais pas assez l'infrastructure de fibre de nœud pour savoir par où commencer à interpréter l'erreur ou à instrumenter le code ...

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

Si je comprends bien, quelque chose se récurrente un peu trop enthousiaste, la pile du serveur explose et elle se bloque. Malheureusement, je n'ai aucune idée réelle où se trouve cette fonction incriminée - j'ai regardé l'appel My Deps.autorun (juste un pour le moment) et cela ne semble pas être le problème. Aucun de mon code n'est implémenté avec une récursivité explicite, et je n'ai aucune raison de soupçonner que de gros objets sont passés. De toute évidence, je ne suis pas vraiment sûr, bien sûr.

Je cherche vraiment des conseils sur la façon d'instruler le code pour me montrer où les choses deviennent incontrôlables. Étant donné que Meteor fait beaucoup dans les coulisses, il serait vraiment utile que quelqu'un puisse me donner quelques conseils sur l'endroit où chercher.

Je reviens juste à cela, et je suis encore assez perdu quant à l'endroit où être à la recherche. cette La mise à jour suggérée du nœud 0.11.x me donnerait plus d'informations, mais cela ne semble pas avoir ajouté plus de détails lorsqu'il se bloque.

Le crash se produit après toute interaction de page - c'est-à-dire que le serveur démarre et fonctionne bien, mais si je recharge dans le navigateur ou interagis avec la page elle-même, boom!

Par demande populaire, voici le code du serveur:

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 ligne intrigue de futur.js n'a pas fourni plus de détails:

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

Et voici les problèmes que je rencontre tout en essayant d'utiliser l'inspecteur de nœud. Je joue avec cela depuis une demi-heure, donc je fais probablement une erreur fondamentale, mais: j'ai installé un inspecteur de nœud via NPM (NPM Install -g Node-inspecteur).

Alors, j'essaye

$ 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

Jusqu'ici, tout va bien. À ce stade, le côté client n'est pas ouvert dans mon navigateur (c'est-à-dire aucun onglet pointant sur LocalHost: 3000). J'ouvre un Tab Chrome pointant vers LocalHost: 5858, et je vois la source de Meteor.js J'ai défini un point d'arrêt sur la ligne 6 de Meteor.js

var Fiber = require('fibers');

puis ouvrez l'onglet Client Meteor (LocalHost: 3000) et le débordement de pile susmentionné apparaît à nouveau. Le débogueur ne s'arrête pas à la ligne 6, ou indique une autre manière qu'il a remarqué. Il en va de même si je définis un point d'arrêt à la ligne 3.

Answer 1

La réponse légèrement plus utile vient du FAQ des météores non officiels:

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

Cela démarre le processus de l'inspecteur de nœud en arrière-plan, puis démarre l'écoute du conteneur de nœud de Meteor avec le bon jeu de drapeaux de débogage. Ouvrant l'onglet Chrome à http://127.0.0.1:8080/debug?port=5858 Permettez-moi de passer.

Pas aussi strictement La réponse à la question, mais la ligne incriminée dans le code ci-dessus semble appeler Meteor.Error dans le code serveur. J'accepterai toujours avec plaisir une réponse à cela qui aurait identifié cela. Je suppose que Meteor.Error n'est pas du tout ejsonable, et en essayant de l'analyser, la pile explose.

Answer 2

Essayer inspecteur de nœud, il permet d'inspecter le CallStack. C'est un Présentation vidéo De comment l'utiliser, visuellement, il ressemble au débogueur Chrome (c'est la même source de base).

Answer 3

Ligne 173 de Future.js transmet une exception à l'écouteur suivant. Il apparaît dans votre cas, le prochain écouteur est l'instance elle-même, résultant en une boucle de crash de pile.

Modifiez votre fichier futur.js (chemin référencé dans OP) et non la ligne Console.log juste au-dessus ... alors vous devriez voir une explication plus détaillée de ce qui se passe. Si la sortie Console.log n'est pas utile à résoudre, publiez ici pour d'autres diagnostics.

Je suppose que c'est lié à un package manquant, par ce fil.