24

I have a server that I can cause to die with the following output:

events.js:38
EventEmitter.prototype.emit = function(type) {
                                  ^
RangeError: Maximum call stack size exceeded

However, without a stack dump or trace, I have no way of finding whether this is infinite recursion or just a slightly-too-large chain, let alone where the problem function is.

Running Node with the --trace option caused my tests to not only run slow (as one would expect), but to not reproduce the problem.

Anybody have any solutions or tips for getting to the bottom of this?

OrangeDog
  • 36,653
  • 12
  • 122
  • 207
  • This particular issue was resolved by comparing diffs before and after this was known to happen, sticking extra logging by every new/changed `emit` call and discovering the scoping error leading to joint-recursion on a `'drain'` event - hence the speed sensitivity. I'll still award accepted answer to the best general strategy that would also have solved this. – OrangeDog Oct 06 '11 at 08:44

3 Answers3

9

It seems the answer is currently: sit tight and wait for Node.js to update to a newer V8 version, or build your own with the patch from this Chromium project bug report.

This archived thread from the v8-dev mailing list shows a discussion in which

  • Dave Smith brings up this very issue and proposes a patch
  • Yang Guo of the Chromium project discusses it, files a Chromium bug against the issue, and applies a different fix
  • Dave notes that Node (0.8 at the time) is using V8 3.11 and asks about backporting the patch. Yang replies that the patch will probably land in V8 3.15 and will not be backported.

Note that Node.js v0.8 used V8 3.11; Node.js 0.10 is currently using V8 3.14. So the patch accepted by Chromium for this issue is still "in the future" as far as Node is concerned.

(This answer owes thanks to @Coderoshi, since it's by following the thread from his answer that I learned all this.)

metamatt
  • 13,809
  • 7
  • 46
  • 56
  • Any news about this? I have the same problem that I've to debug a "RangeError: Maximum call stack size exceeded". The problem is that it occurs in a unchanged webapplication since a few days and I don't know how to search, so a stacktrace would be a great help. – morten.c Aug 22 '13 at 17:24
  • Node 0.11 is using a new enough version of V8 to show stack traces in this situation. If you're able to run your webapp under Node 0.11, try that. – metamatt Aug 22 '13 at 18:29
  • 1
    Just tried v.0.11.6, although I was able to run the webapp, stack traces didn't work. Anyhow I fixed the bug, but I thought this comment could be useful for people with similar bugs searching for a stack trace. Maybe it saves somebody time, not to compile the unstable version ;-). – morten.c Aug 26 '13 at 14:12
4

The chance of it being a "slightly-too-large chain" seems unlikely.

It's probably a function calling the event that triggered itself.

So if the slowing down of the code is making the infinite recursion to stop. My guess would be that you have a queue and with the slower mode its not getting filled up as fast.

If this doesn't help then I think I need more info. Maybe someone has a catch-all for this though.

MD Sayem Ahmed
  • 28,628
  • 27
  • 111
  • 178
megakorre
  • 2,213
  • 16
  • 23
2

This patch might help you find a solution. It expands the stack trace tremendously:

https://github.com/dizzyd/node/commit/40434019540ffc17e984ff0653500a3c5db87deb

Coderoshi
  • 364
  • 3
  • 5
  • This does seem like the right approach. I wouldn't describe this patch as "expands the stack trace tremendously"; I would describe it as "tries much harder to construct a stack trace for stack overflow exceptions". BTW, the code modified by this patch contains a reference to TODO(1240995); anyone know what bug database that's referring to? – metamatt Mar 27 '13 at 16:29
  • I didn't find any bug 1240995 but I did find what became of dizzyd's patch; see http://stackoverflow.com/a/15664576/275581. – metamatt Mar 27 '13 at 16:50