I have an app built in node.js and I use the node inspector in order to debug.
But it's quite hard because of this:
My breakpoints are never saved after I restart the server
I cannot put a breakpoint on a file that has not loaded yet; so I have to step into from the first script to the one I want; REALLY PAINFULL!
How do you really debug node.js with node inspector?
The videos on how to use node.js are quite misleading as everything is into a module...
http://www.youtube.com/watch?v=AOnK3NVnxL8
or this one the scripts appear are already loaded in the first script
http://www.youtube.com/watch?v=HJOH0-g8f6E&feature=mfu_in_order&list=UL
Edit:
Nobody can answer this question? :s
In javascript you can set breakpoints using the debugger; statement. However, they will only pause node if a debugger is actually attached.
So launch your node script using
node --debug-brk myfile.js
then launch node-inspector and press the play button to continue to the next breakpoint and it will hit your debugger; breakpoint (at least that works for me ATM)
(as noted in the comments: in recent versions of node you no longer have to separately install node-inspector. If you launch node using node --debug-brk --inspect myfile.js you get a url that launches the debugger in your browser).
you still need one extra click after restarting, but at least your breakpoints are saved.
if your breakpoint is not hit automatically, but only after some user action you don't need the --debug-brk of course.
The problem with client-side breakpoints is that it's hard to keep track of the breakpoint position when the file changes. Unlike in an editor, it cannot keep track of lines being changed, etc.
#RyanOlds suggestion of using debugger; statements is also a good one, but you have to make sure the debugger is connected before the statement is evaluated, because it is ignored otherwise. Starting with --debug-brk is a good way to force this, because the execution is paused on the first line allowing you to attach the debugger and then continue the execution.
You could try debugging with node's internal debugger.
Edit: However, according to the v8 DebuggerProtocol it's possible to set breakpoints on script that hasn't been loaded yet AND you can set breakpoints by function, script and more. It should therefore be possible for node-inspector to keep track of your breakpoints (in a session, or whatever). It doesn't do so right now, though.
Maybe if v8 allows a certain piece of code to trigger a breakpoint, similar to nodes debugger?
Edit: It does, you should be able to trigger a break by throwing any old exception (caught or uncaught).
The new version (0.3.x) of node inspector saves breakpoints in browser's local storage and restores them automatically.
https://github.com/node-inspector/node-inspector/pull/116
Try using IntelliJ WebStorm - there's a free trial and licenses aren't outrageously expensive. It lets you save breakpoints in all your files prior to starting up its own internal node process and remembers them across process restarts.
I agree - node-inspector looks brilliant, but is quite useless unless your app has a clear place to set a breakpoint in the top level script just after your source files have loaded, but before you hit the area you want to debug. You can structure your own code this way, but you won't be so lucky with other helpful libraries you want to include. Also... why should a debugging tool dictate your project structure!
Forgetting breakpoints is extremely unhelpful... most of my debug runs take more than one walkthrough, as in other people's code it's easy to step past where you want to be.
You can use node-codein for inspection. It won't do runtime breakpoints but it should ease the inspection process.
https://github.com/ketamynx/node-codein/
Also worth noting.. vscode has a great debugger for node.
https://code.visualstudio.com/
Available on Mac, Linux, & Windows.
It does runtime breakpoints (without the need of writing debugger; statements),
supports variable watches, and even has a call stack window (very nice).
Everything is so automated, it is now my goto over sublime text when using nodejs (and I LOVE sublime).
This is built in now including saving breakpoints. I just tested it in node 7.3.0.
node --inspect --debug-brk app.js
This prints a url like this
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/c3d5d93e-9d27-41b9-a4da-607e43c9d4f8
Put that in Chrome and you're good to go.
If you want to skip copy/pasting the url, do this:
npm install -g inspect-process
inspect --debug-brk app.js
Unfortunately the inspect-process method doesn't retain the breakpoints :-(.
Here's a video I made: https://youtu.be/rtZKUnks6jI
Related
Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:
In all of my searching, I have not come across any trick, plug-in, or setting that would allow me to pre-populate a Watch Window for use during debugging.
The well-known steps to watch a variable in Visual Studio 2017 is to set a breakpoint (perhaps on the first instance of a variable being assigned a value), then, adding the variable to a Watch Window. On subsequent runs, that watched variable should remain in the Watch Window.
Is there a way to accomplish pre-populating the Watch Window before a debugging session? I have code that runs in a timed sequence. Taking the extended time during an execution break to pause and set up a watch causes the program to crash. Such timeout crashes while setting up variable watch objects makes for difficult interaction with the debugger. Pre-populating the watch list would help considerably.
I know that I could use a technique such as using Debug.Print(...) statements, which are printed to the Output Window during code execution. However, this doesn't allow me the control and visual feedback to my debugging efforts that comes from a Watch Window.
Watches can only be evaluated when you are paused in the debugger, say on a breakpoint. They can't be evaluated during normal execution. Your options to get around this limiation are:
Add Debug.Print(...) or something similar to your code that outputs a value.
Similar to #1 add a TracePoint which you'll find in the actions setting of a breakpoints setting (that's the gear icon when you hover over a breakpoint). When the TracePoints are hit they will then evaluate the expression that you specficied in the actions window and log it to the Output window. The advantage of TracePoints over adding your own logging is that you can turn it off and on without building your code. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/using-breakpoints?view=vs-2019#BKMK_Print_to_the_Output_window_with_tracepoints
Use the VS Enterprise only feature Snapshots which is part of IntelliTrace. Basically set your breakpoints but rather than stopping on them to look at the watch just continue. Each time you stop a snapshot of the process will be taken capturing the state of your application at that time. Then once you're finished use the Diagnostic Tools window to select each of the snasphots and activate them. For each snapshot you can use the debugger just as if you stopped the application. So you can use watches and inspect etc. Of course you can't step as the app has already ran but you can go to the next snapshot etc. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/view-snapshots-with-intellitrace?view=vs-2019 and https://devblogs.microsoft.com/visualstudio/step-back-while-debugging-with-intellitrace/
How Can Watch Variables be Configured in a Watch Window Before Running
a Debug Session in VS2017?
I'm afraid the answer is negative.For now,the Watch window can only be configured after the debug session start.It's like a runtime window only occurs during debugging.
So we can't pre-populate it before debug session for now. In other words, it's by design.
As alternative ways,you can follow Andy's detailed suggestions above.
And since your needs is meaningful in some specific debugging situation, you can also post your suggestion on development community like a user voice to add a new feature.
Where XCode generate error for application crash ?
I'm crazyng ! My application when open second file xib with webview then it crash. But I don't know why ? how can i Know where is error ?
You need to learn how to use the debugger in Xcode.
Run your app under the debugger then instead if simply getting a stack trace Xcode will stop at the line the fault occurs and show you your code and variables. You can then examine the contents of your variables, the call tree, etc. and hunt down the problem.
Once you know the general area of the problem you can place breakpoints to pause your application before the problem occurs and check whether your variables have the values expected etc. Then you can run till the next breakpoint, or step through your code a line at a time.
You can add code, such as NSAssert's and NSLog's to your app to check progress and display information without stopping the run, etc.
It's a process, and some problems will be harder to track down, but you'll get quicker at it with practice.
The Xcode documentation will tell you all about the debugger.
HTH
I've installed node-inspector just to find out that it doesn't support breakpoints :| What's the point in it at all, bearing in mind that on big part node code is asynchronous and you simply cannot follow it step by step?..
I'm definitely missing a point here...
Anyway to debug node code with breakpoints and everything?
yupp, I've successfully used node-inspector. If you want permanent breakpoints, simply insert debugger; in your code. See http://nodejs.org/api/debugger.html.
Making node wait until a debugger is attached, using node --inspect-brk script.js (previously node --debug-brk script.js), can also be very helpful.
(For Node 8 and later)
Node.js has a built-in debugger. Normally you can turn on the debugger in two ways:
Start your Node.js app or script with the --inspect or --inspect-brk switch. For example:
$ node.js --inspect index.js
(Note: --inspect-brk breaks before user code starts)
If for some reason you cannot start your Node.js app or script with the --inspect switch, you can still instruct the Node.js process to start listening for debugging messages by signalling it with SIGUSR1 (on Linux and OS X). For Node 8 and later it will activate the Inspector API, same as the --inspect switch
$ kill -sigusr1 23485
(Note: you need to replace 23485 with your own Node.js process ID)
With the debugger turned on, you can open the Google Chrome browser, and type in the address bar chrome://inspect
Then you should see an entry listed under "Remote Target". Go ahead and click "inspect".
Now you can set breakpoints and start debugging your code.
Reference:
https://nodejs.org/en/docs/guides/debugging-getting-started/
Related issue on stackoverflow:
Chrome Devtools Dedicated Node.js Inspector not stopping at breakpoints
To debug a Node.js application, one can use the debugging built-in method:
(1) Insert debugger; statement where you want to insert a break point
(2) Run the file with command $ node inspect <file name>
(3) Use a key for example, c to continue to next break point
You can even debug values associated to variables at that break point by typing repl. For more information, Please check the official guide.
Have you tried using nodemon library? it can be found here.
For development purposes you could start the app running nodemon. I have this script:
"dev": "nodemon --inspect src/index.js"
It will break any time a debugger statement is reached in the code. To open the console where you can see the server code, open the console in chrome and click on the nodejs icon:
It also helps you refreshing the server every time you save any file on the server.
Let me know if it works!
Just to elaborate a bit here:
Set a debugger wherever you want the breakpoints to be and then run your code with node debug script.js/index.js
When the debugger stops at you breakpoint, you will need to repl to inspect the variables.
I can't see my source file in the scripts list, but I can see them in the call stack.
I have made a breakpoint in my source-file but sometimes it just doesn't want to show my source files in the node inspector.. but only sometimes :s that's the problem
anyone knows how to make this work well?
thanks a lot
You must refresh the browser where you have node inspector started. I think I had the same issue.