I have a Node js application (running on Windows) which occasionally "hangs" - it gives no sign of progress. From Visual Studio Code, I attach the debugger by selecting the process ID. Evidence of successful attachment is given both from within VSC and standard out (console):
"Debugger listening on ws://x.y.z.1:9229/242f50ce-a43c-48dc-9926-23520ed10ed3
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached."
However, the process continues to run and clicking on the "pause" symbol in the debugger control bar un-ghosts momentarily but does not change to the "continue" symbol (other control symbols on the bar remain ghosted).
Launch configuration:
{
"launch": {
"configurations": [
{
"name": "Attach by Process ID",
"processId": "${command:PickProcess}",
"request": "attach",
//"skipFiles": [
// "<node_internals>/**"
//],
"type": "node"
},
{
"name": "Launch Program",
"program": "${workspaceFolder}/index.js",
"request": "launch",
"skipFiles": [
"<node_internals>/**"
],
"type": "node", "args": ["set", "31100-1", "subsets" ]
}
]
},
"workbench.colorTheme": "Default High Contrast"
}
On occasion when I attach and then detach ("Stop Debugging") the process seems to continue and behave normally (no longer hung), but I am not able to discover where and/or why it is hanging.
I should add that while this Node js program runs from both a windows power shell and a Cygwin tcsh, it is when running from the Cygwin that I am seeing this behavior (insufficient testing from power shell to say whether or not this ever occurs)
I can understand that the source might not be visible from VSC or that the callstack would be abbreviated/incomplete, but I would expect the process to stop. Perhaps it has and I am misinterpreting the VSC presentation.
Any discussion or suggestions are welcomed. I am both a Node js and VSC novice.
Related
I have a javascript program that launches a script inside it with the following command:
node --inspect file.js.
When it happens, I would like VSCode to auto attach debugger to the child process. This is my config in launch.json:
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Start with Yarn",
"autoAttachChildProcesses": true,
...
}
auto attach is set to 'SMART'.
So I launch the program with the configuration, wait for the script to get called inside the program and... VSCode does not automatically attach a debugger to it. Why is that?
I want to set up my VS Code debugger to debug my Next.js app. My launch.json contains the below settings:
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "attach",
"name": "Launch Program",
"skipFiles": ["<node_internals>/**"],
"port": 9229,
"resolveSourceMapLocations": [
"${workspaceFolder}/**",
"!**/node_modules/**"
]
}
]
}
I also added the debug script to my packege.json:
"debug": "NODE_OPTIONS='--inspect' next dev"
First, I run npm run debug in my terminal, then I launch the debugger in the VS Code Run and Debug tab. The debugger is attached, but when I start adding breakpoints, some of them work properly (the dot indicating the breakpoint is red and the app stops when the breakpoint is hit), but most of them are ignored despite the red indicator. There're also some unbound breakpoints.
I spent a few days figuring this out with no effect. I really look forward to moving past console-logging for debugging purposes.
VS Code version: 1.57.0
I am attempting to debug an electron app in vs code (the main process, not the renderer process). The project I am trying to debug is this repo:
https://github.com/hello-efficiency-inc/raven-reader
it works really nice, once you have it cloned, and the right things are installed. Then I can just run:
yarn electron:serve
And boom, it runs nicely.
But I would like to also debug this. So I look around a bit, and find that I should probably use this launch.json file in the .vscode directory:
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Electron: Main",
"protocol": "inspector",
"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron",
"runtimeArgs": ["--remote-debugging-port=9223", "."],
"windows": {
"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron.cmd"
}
}
]
}
In my package.json, I have this line for finding the startfile:
"main": "./src/background.js",
So, I try to run by clicking the debug icon, and then green triangle where it says
run and debug | Electron:Main
Which gives me this in the call stack menu:
But nothing actually seems like it's running, I dont see any desktop window which I would like so I can actually debug, and I can't hit my breakpoints either
Best way to sort this is to install code runner extension in vscode
I am working on a node.js application using express.js as a web framework listening on PORT 3000.
I am using VS Code v1.46.
My launch.json file is
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceFolder}\\WebApi\\index.js",
"restart": true,
"protocol": "inspector"
}
]
}
I am able to start the debugging session for the first time, but 2nd time onwards, I get error Error: listen EADDRINUSE: address already in use :::3000
This error is because VSCode didn't terminate the node.exe process created in 1st debugging session and so in the subsequent session node failed to start the express server on port 3000 as it is still in used.
Can anyone help me to configure VSCode to terminate node.exe process once I stop the debugger?
This issue started just last week for me, not sure why, maybe windows update.
Any way I found the following :
https://github.com/OmniSharp/omnisharp-vscode/issues/2387
where they say that if you add to launch.json
"console": "externalTerminal" or "console": 'integratedTerminal'
it will open a console for the process so that u can kill manually
It works fine with the Using the "preview" debug extension.
This is the launch.json for using that mode, just make sure that you put the correct command of your package.json.
{
"version": "0.2.0",
"configurations": [
{
"type": "node-terminal",
"name": "Run Script: start",
"request": "launch",
"command": "npm run start",
"cwd": "${workspaceFolder}"
}
]
}
I am trying to get VSCode 1.20.1 to break at a breakpoint in my project, but it simply refuses to break (at least with the inspector protocol). I've distilled this down to a 3 line Node.js sample project which can be found here on GitHub, I'll paste the relevant sections below.
The index.js program is a simple Hello World with a delay to avoid any debugger attach races (more on that later).
setTimeout(() => {
console.log('Hello'); //Breakpoint is set here
}, 5000);
The launch.json is below:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Normal Run",
"runtimeExecutable": "${workspaceFolder}/bin/node",
"runtimeArgs": [
"--nolazy",
"--inspect-brk=0.0.0.0:5858"
],
"program": "${workspaceFolder}/index.js",
"args": [],
"env": {
"DOCKER_ARGS": "-p5858:5858"
},
"address": "127.0.0.1",
"port": 5858,
"timeout": 60000,
"console": "integratedTerminal",
"smartStep": true,
"stopOnEntry": false,
"protocol": "inspector",
"autoAttachChildProcesses": true,
"localRoot": "${workspaceFolder}",
"remoteRoot": "/src"
}
]
}
Note that Node.js is running in Docker in the standard node:8 container with a volume mount of the local source directory (that is what the runTimeExecutable is for, see GitHub). If I use Wireshark to monitor port 5858, I can see the debugger attach and decode all messages. Strangely, VSCode issues the Runtime.runIfWaitingForDebugger immediately, and then later issues the Debugger.setBreakpointByURL message that seems to be accepted by Node.js (it successfully returns a Location for the breakpoint). I have the 5 second timeout in the code just in case this race is the cause of the problem (which it does not seem to be).
As an aside, if I use my host Node.js (6.11.4) with the protocol as legacy (or auto which chooses legacy) and comment out the runtimeArgs, runtimeExecutable, etc. VSCode hits the breakpoint. If I force the protocol to inspector (which is experimental in 6.11.4) and add back the runtimeArgs (but not executable) the debugger attaches but no breakpoint is hit, essentially the same behavior as with the Docker node:8 above.
What am I doing wrong here? This problem originally started in a new TypeScript project using sourcemaps and mocha, etc. but I've boiled it down to this.