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?
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.)
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.
This patch might help you find a solution. It expands the stack trace tremendously:
https://github.com/dizzyd/node/commit/40434019540ffc17e984ff0653500a3c5db87deb
Related
Newbie question here, it seems... I'm losing my mind. Why is this so hard? I've been programming other languages for years, but I'm relatively new to node and JS. I've read and watched as much as I can find official and unofficial on the web about this and it's either years old or significantly different from my situation, so not very helpful.
I'd really, really appreciate anyone who can understand my (pretty simple, I would have thought!?) specific case and help me get this set up to just work. Possible?
macOS 10.15.6 Catalina.
As I understand it, node comes with the OS. It's Node.js 12.8.1
VS Code 1.48.2
I create a new file, name it abcd.js. VS Code figures out it's javascript. I add some code - read a file of JSON from the disk, make some changes, console.log some stuff (appears under the Output tab). I run it.* All good and works.
Now... Run menu > "Start Debugging". Or, There's a Run/Debug icon in the sidebar that shows a "Run and Debug" button which I click on. Both of those ask me for an environment - I choose Node.js, and the Debug console outputs this:
/usr/local/bin/node path/to/my/file.js
Debugger listening on ws://127.0.0.1:56430/30b0c2aa-278b-4540-94c4-825d30b94f57
For help see https://nodejs.org/en/docs/inspector
And that's it. I have breakpoints, but it doesn't stop on them. Something happens (too quick to see what it is). I don't think it's actually running my code because nothing new shows up under the Output tab.
There's also a note in that sidebar saying "To customize Run and Debug create a launch.json file." I've experimented with that as much as I can, but nothing I do seems to help.
I've been programming for years. I'm used to other languages and IDEs (eg. C, Java, AppleScript, Swift, others), where you open the IDE, write some code, hit run (or debug), it may or may not build a target (depending on the language and environment), but then it runs the code (opens the target app, or runs in the IDE, and allows you to step through the code, breakpoints, etc. in the IDE if debugging). Is JS/node programming radically different from this somehow?
*One theory:
I'm not doing this through any terminal or any browser. Maybe that's the problem...? At some point I installed a "Code Runner" plugin that I believe is what is running my code. It was a while ago, but if I recall correctly maybe I turned to that because I was looking for the experience I've described above, and this plugin gave me that where the "normal" node setup process didn't? Perhaps my problem is that that plugin simplifies RUNNING js scripts so much that my issues with DEBUGGING exist because that plugin allows me to bypass other usual complications with running JS/Node scripts (but doesn't have any debugging functionality of its own)?
My thanks to #ippi for his/her comment with a gif video. Not sure if the following really answers my question, but I'm posting it in case it helps anyone else.
I took some time to clean up my Mac a little, and I completely uninstall VSCode, all its extensions and supporting files and started again.
I re-installed Code from scratch, didn't add any extensions, and then tried what #ippi's video showed.
It still didn't work - I got more or less the same output as in my post, and I'm not sure if it was running the code or not.
I had an urgent deadline to meet so didn't come back to it till now - two days later - and now, it's working.
A couple of things changed in that time though I really don't know what fixed this, if it was either of those or anything else. The two changes I can remember that I've done the last two days are:
Despite my post saying my node was 12.8.1, sometime in the last couple of days it turned into 8.something. I updated it to the latest v12.8.3, and
to meet that deadline I used node inspect myfile.js in Terminal for a bit.
The inspect (mostly) worked to meet my deadline, but still a hassle compared to what's shown in #ippi's video. I definitely wanted to get it working that way.
So… updating node fixed it? Running it in the terminal for a bit fixed it? Something else? I'm at a loss to know what did it. But it's working now.
Thanks again to #ippi for that. It pointed me in a good direction at least - to clean up my install a bit, if nothing else.
Maybe this will help someone else sometime in the future.
It seems the ultimate answer is:
It should just work out of the box (possibly subject to updating node to its latest). If it doesn't then:
The issue most likely isn't that you have to do any fancy configuring or whatnot to make it work.
Instead, most likely something is wrong with your installation and/or OS and you should explore that.
#ippi's video attached in case his/her link ever breaks:
Does anyone have a good reference for all of the --js-flags="" that can be used in Chrome at the command line, for Windows?
For performance testing, I'm currently using:
chrome.exe --no-sandbox --js-flags="--trace-deopt --trace-opt"
But, I'd like to know if there are other flags that will help illuminate a problem I'm having.
Specifically, other's have referenced --trace-bailout, but that one doesn't seem to work; it's unrecognized by Chrome; I'd love to see which functions aren't being optimized by Turbofan.
V8 developer here. The authoritative list of V8 flags is the source: https://chromium.googlesource.com/v8/v8/+/master/src/flags/flag-definitions.h#188
When that file has, e.g., DEFINE_BOOL(es_staging, ...), then the corresponding command-line syntax in Chrome would be --js-flags="--es-staging".
I'd love to see which functions aren't being optimized by Turbofan.
Turbofan optimizes all functions, assuming they run long enough. (Many years ago, there was a set of features that Crankshaft couldn't optimize; those days are long gone, Turbofan supports everything.)
Here's a suggestion. I had no idea there were so many options!
https://peter.sh/experiments/chromium-command-line-switches/
(Last automated update occurred on 2019-08-12.)
I've googled for 'V8 mksnapshot' and found out that there is a 'snapshot' feature in V8 engine, also there is this question here
This feature seems to be an outstanding feature for bug reproduction in case of Node.js server fault.
The scenario
You use 'process.dumpAll' in some error-handler of Node.js server, maybe attach it process-wise, maybe filter error events somehow.
If a problem occur - all the V8 state is saved into a dump-file
Later when you want to reproduce the problem you can re-run Node.js from this dump
You than attach a debugger to Node.js, the process would be on in suspended state - same thing if 'debugger' is triggered, current statement would be 'process.dumpAll' function.
Now you can inspect every objects' state in V8.
I'd like to ask
Where can I find better documented (better than some chatting on forum) more info about V8 snapshots?
Do you see any pitfalls for this scenario?
What are the first steps should I take to implement a function 'process.dumpAll' and 'process.loadAll' for Node.js? (excluding knowledge about writing Node.js extensions)
Maybe someone is already making or made some solution for this?
V8's mksnapshot feature is not designed for postmortem debugging (but for startup acceleration), and I doubt that it could be useful for that purpose.
Coredumps (for crashing processes) and DevTools / heap snapshots (for exceptions) are in all likelihood more useful for debugging purposes.
There are some existing efforts for Node.js postmortem debugging. Maybe just knowing the right search engine query can help you get an overview of existing solutions, their abilities and limitations?
I have a single process node.js application, which I wish to debug with Intellij IDEA 11 32 bits (node.js is 32 bits too).
So, I place an initial breakpoint and run. The debugger stops at the breakpoint, but then it refuses to do any of the following:
step into
go to another breakpoint
pause execution
When I step into, it seems just to run, without stepping through the code. Once running, it ignores any subsequent breakpoints and does not break when I press the pause button.
This issue drives me crazy.
Any ideas on how should I troubleshoot it?
EDIT
More info. After IDEA breaks on the first breakpoint (the only successful time) I try to inspect the variables and am unable to see any. IDEA is stuck on "Collecting data..." The watch window does not work too.
EDIT2
Justed posted an issue to their bug tracking system - http://youtrack.jetbrains.com/issue/IDEA-112925
I've been noticing that IntelliJ's node.js debugger kinda sucks. It's death by 1000 cuts. I love IntelliJ to death, its such a nice IDE. But for node, the debugger has a million different scenarios where breakpoints don't work properly, and another million where it doesn't properly give you access to the in-scope variable values, and another million where it doesn't step properly...
I'm gonna hafta try looking for another tool..
UPDATE 2014-01-13: I've been using IntelliJ's debugger for a while now (having found no other good tool). It seems some of the problems with it are problems with node or v8 itself. Most of the problems I was having have either actually been solved by newer versions of IntelliJ, or by using this workaround:
1. create a file called proxyDebug.js
2. put the following content in it:
require('path/to/the/script/you/want/to/debug.js')
3. point your debugger to that file
Apparently the node.js debugging hooks go buggy at the entrypoint script, so by creating this proxy entrypoint that we don't care at all about, there won't be any weird bugs caused by that in the scripts you do care about. The bugs this workaround fixed were missed breakpoints, predefined variables (exports, module, process, etc) being inaccessible by the debugger, and one or two other things I can't remember.
Last WebStorm version I tried (7.0.3) actually takes ages in collecting data but eventually works. If it seems stuck to you, try to leave it for a minute
The project I'm working on involves a "planning" screen, which is entirely made with backbone.js (the other pages of the app are not).
My issue is that from times to times, chrome freezes and the web view stop responding to any interaction. Sometimes, I can manage to quit chrome itself, but usually the controls does not answer either.
I'm pretty convinced this is related to the js code. It seems to me that when a script takes too much time, or loops indefinitely, Chrome can detect this and interrupt the script. However, since this is not the case, I'm thinking that too many js objects stay in memory.
Whatever the cause is, I would like to know which chrome dev tools can help me here. While I'm not a beginner in js, asides setting breakpoints and calling console.log, I have no idea how to debug JS apps. I'm not opposed to use another browser if the dev tools are more suited.
Thanks a lot for your time !
FTR : This is a rails 3.2.8 app, using mongodb, & Backbone.js 0.9.2. The js code is written in coffeescript. This issue happened on my macbook air 2012 running mountain lion, as well as on the client machine which runs on windows 7. The issue appeared at least on chrome 22 & 23.
Using the Javascript CPU profiler, I was able to find the group of functions that seems to be responsible for the freezing.
I'm still open to any advice/ressource on debugging javascript code.
Make a console.log in the loop and check if its the same point freezing on all chrome versions. There is a limit see Browser Javascript Stack size limit.
Maybe add some code? Because there could be some memory leaks especially with event handlers!
What I would do is the long and weary approach to getting your hands dirty with console.log. --- in this case.
In your case, and THX for the hint by the way (finding the offender with the CPU profiler, I'll try that next time round), I guess the offenders might be some functions "callbacking" themselves .. probably via some sort of event-handling/bubbling/callback-combination.
What happens then usually is that it just doesn't recognize the endless-loop, because the callback-stack is kinda "broken". Therefor it will never throw a browser-error.
If you have any luck, it doesn't kill the browser quick enough to kill the console. I did have that at times, the console killed (remaining silent), the coffeescript files not even loaded in the debugger (I use a JIT-coffee-to-js-translator as in JS-MVC) ... the page frozen or not doing anything ...
So, if indeed you are lucky and the debugger spits out your console.logs you can thereby guess where your unwanted loop is hiding. Just by looking at the repeated order of the output statements.
of course you know you can set breakpoints right? even conditional breakpoints
I'm currently struggling a bit untangling a similar sounding loop - i guess in case of emergency some alert() calls in your code would at least slow the loop down
or maybe some wait calls (bad idea)
my loop is running so fast I loose my console log!