Tracking down stack overflow in meteor/node fiber

Question

I'm seeing this crash now and am not familiar enough with the node fiber infrastructure to know where to begin interpreting the error or instrumenting the 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

As I understand it, something is recurring a little too enthusiastically, the server stack blows up, and it crashes. Unfortunately, I have no real idea where this offending function is--I looked at the my Deps.autorun call (just one at the moment) and it does not seem to be the trouble. None of my code is implemented with explicit recursion, and I don't have any reason to suspect large objects are being passed around. Obviously, I'm not really sure, of course.

I'm really just looking for advice on how to instrument the code to show me where things are getting out of hand. Since Meteor's doing a whole lot behind the scenes, it would be really useful if anyone could give me a few pointers as to where to look.

Just coming back to this, and am still pretty lost as to where to be looking. this suggested updating to node 0.11.x would give me more info, but doing that doesn't seem to have added any more detail when it crashes.

The crash happens after any page interaction--that is, the server starts up and is functioning ok, but if I reload in the browser or interact with the page itself, BOOM!

By popular demand, here is the server code:

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

uncommenting line 172 of future.js did not provide more details:

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

And, here's the trouble I run into while trying to use node-inspector. I have been playing with this for the past half hour, so I'm likely just making some fundamental error, but: I installed node-inspector via npm (npm install -g node-inspector).

then, I try

$ 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

so far, so good. At this point, the client side is not open in my browser (i.e. no tab pointing at localhost:3000). I open up a Chrome tab pointing to localhost:5858, and see the source for meteor.js I set a breakpoint on line 6 of meteor.js

var Fiber = require('fibers');

and then open the meteor client tab (localhost:3000) and the aforementioned stack overflow pops up again. The debugger does not halt on line 6, or in any other way indicate that it has noticed. Same is true if I set a breakpoint at line 3.

Answer 1

Try node-inspector, it allows to inspect the callstack. This is a video presentation of how to use it, visually it looks like the chrome debugger (it's the same base source).

Answer 2

The slightly more helpful answer comes from the unofficial Meteor FAQ:

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

This starts the node-inspector process in the background, and then starts meteor's node container listening with the right debugging flags set. Opening the Chrome tab to http://127.0.0.1:8080/debug?port=5858 let me step through.

Also, not strictly the answer to the question, but the offending line in the code above seems to be calling Meteor.Error in the server code. I'll still gladly accept an answer to this that would have identified that. I'm guessing that Meteor.Error is not at all EJSONable, and in attempting to parse it, the stack explodes.