Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack overflow running tests in node 0.10 #73

Closed
metamatt opened this issue Apr 3, 2013 · 4 comments
Closed

stack overflow running tests in node 0.10 #73

metamatt opened this issue Apr 3, 2013 · 4 comments

Comments

@metamatt
Copy link
Collaborator

metamatt commented Apr 3, 2013

I tried running tree-construction-test.js in node 0.10, and test case data/tree-construction/tests25.dat-19 failed first with a few hundred repeats of

(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.

and then finally

RangeError: Maximum call stack size exceeded
@cscott
Copy link

cscott commented Apr 17, 2013

I know mocha had similar issues, see mochajs/mocha#777 -- so this might be a bug in the test runner, not in html5 itself.

@metamatt
Copy link
Collaborator Author

Note that html5 is using node-tap, not mocha, as its test runner.

I expect it is a similar issue where nextTick should be replaced with setImmediate, though.

I find stack overflows really painful to troubleshoot in the current Node releases because you get no context (call stack) at all. This is actually due to V8, not Node, and V8 fixed this a while ago, and I've been eagerly awaiting it showing up in Node (it showed up in V8 3.15, Node 0.10 is using V8 3.14, Node 0.11 unstable cycle releases are now at V8 3.16.17) so I built node from current 0.11 bleeding edge source the other day to try this out. For this issue I get this stack trace:

RangeError: Maximum call stack size exceeded
    at node.js
    at maxTickWarn (node.js:379:9)
    at process.nextTick (node.js:480:9)
    at onwrite (_stream_writable.js:250:15)
    at WritableState.onwrite (_stream_writable.js:92:5)
    at WriteStream.Socket._write (net.js:634:5)
    at doWrite (_stream_writable.js:211:10)
    at writeOrBuffer (_stream_writable.js:201:5)
    at WriteStream.Writable.write (_stream_writable.js:172:11)
    at WriteStream.Socket.write (net.js:596:40)

which is something, but not enough to go on. Invoking node with --throw-deprecation turns out to be more helpful, as it gives us a call stack from the first offense (when process.nextTick finds recursive invocations), not the last offense (when it's happened so many times the stack overflows). That gives us

Error: (node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.
    at maxTickWarn (node.js:375:15)
    at process.nextTick (node.js:480:9)
    at onwrite (_stream_writable.js:250:15)
    at WritableState.onwrite (_stream_writable.js:92:5)
    at WriteStream.Socket._write (net.js:634:5)
    at doWrite (_stream_writable.js:211:10)
    at writeOrBuffer (_stream_writable.js:201:5)
    at WriteStream.Writable.write (_stream_writable.js:172:11)
    at WriteStream.Socket.write (net.js:596:40)
    at TapProducer.ondata (stream.js:51:26)
    at TapProducer.EventEmitter.emit (events.js:95:17)
    at TapProducer.write (/Users/magi/src/open/html5/node_modules/tap/lib/tap-producer.js:37:8)

Still not enough frames to see all the way from one nextTick call to the recursive one, but it does point the finger generally in tap's direction. Without taking the time to deeply understand the tap code, I found two uses of process.nextTick in its codebase proper, changed both to setImmediate, and reran the tree-construction-test.js, and it does survive the test25.dat-19 test case that stack-overflowed before.

However the tests run much more slowly, and basically tie up the CPU. So this doesn't seem like a good idea.

@aredridel
Copy link
Owner

Oh, excellent! Thank you!

@aredridel
Copy link
Owner

This should be mostly better now -- can you try?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants