Running a gdb command before attaching it to a process via Visual Studio Code - postgresql

I am trying to step through Postgresql code using Visual Studio Code as my IDE on Linux. I am using attach to a process config in launch.json to achieve the same. Following is the launch.json config:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "attach",
"program": "/usr/local/pgsql/bin/postgres",
"processId": 4165,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true,
}
]
}
]
}
When I start Debugging via the GUI, it attaches to the process. But whenever I add a breakpoint, I get the following message printed on the debug console:
Program received signal SIGINT, Interrupt.
0x00007ff5d084e31b in epoll_wait () from /lib64/libc.so.6
And fails to add the breakpoint. From the Postgres developer documentation (link) it is clear that we need to bypass the interrupts arriving at gdb by issuing the following command to gdb:
handle SIGUSR1 noprint pass
I think this command in gdb can be executed only before attaching the process for debugging. Hence when I run this command via the debug console on Visual Studio Code, I get the following error:
Unable to perform this action because the process is running.
Is there a way to instruct the Visual Studio Code debugging, to issue the "handle SIGUSR1 noprint pass" into gdb before it attaches the target process via gdb?

After more research, I found a way to achieve this using ~/.gdbinit file. This file can have commands that will be run each time gdb is run. I have the following content in it:
handle SIGUSR1 nostop noprint pass
handle SIGINT nostop noprint pass
Now what happens is since SIGINT is being overriden, every time the IDE is disconnected from the process, it has be restarted because it cannot disconnect gracefully anymore.

Consider to define these commands in section setupCommands of launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "debugging of local server",
"type": "cppdbg",
"request": "attach",
"program": "/usr/local/pgsql/bin/postgres",
"processId": "${command:pickProcess}",
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "ignore SIGUSR1 signal",
"text": "handle SIGUSR1 nostop noprint pass"
}
]
}
]
}

In addition to Keshav's answer.
You may also add another command to the ~/.gdbinit file :
set auto-load safe-path /
This will tell the compiler that it can use the local .gdbinit file in your working directory.
Now you can make a separate .gdbinit for each project / directory and have them configured independently and not clutter up the global .gdbinit.

Related

Unbound breakpoint while debugging Karma tests in VS Code

I'm trying to debug Karma tests using VS Code. I managed to run tests and attach VS Code to the headless Chrome. The problem is that breakpoints don't work after attaching VS Code. But the "debugger" keyword works well and after stopping on it, I can set new breakpoints, and it works, but old breakpoints remain unbound.
Here are my configs:
launch.json
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "attach",
"name": "Debug Karma",
"address": "localhost",
"port": 9333,
"preLaunchTask": "Start Karma",
"trace": true,
"pathMapping": {
"/": "${workspaceRoot}/",
"/base/": "${workspaceRoot}/"
}
}
]
tasks.json
"version": "2.0.0",
"tasks": [
{
"label": "Start Karma",
"type": "npm",
"isBackground": true,
"script": "test-by-karma-dev",
"problemMatcher": [
{
"pattern": [
{
"regexp": ".",
"file": 1,
"location": 2,
"message": 3
}
],
"background": {
"activeOnStart": true,
"beginsPattern": "karma start",
"endsPattern": "Connected on socket"
}
}
]
}
]
I'm experiencing the exact same behaviour. Did you manage to solve this in the meanwhile?
I found some kind of other workaround, but it isn't any better then placing a debugger statement.
But if you press the debug button on the karma html page it opens up a new tab to /debug.html. After this attach vscode to chrome. Then the breakpoint remains bound. But the problem is that the tests have already run by then. So you have to refresh the browser tab to rerun the tests, but at that moment the breakpoint becomes unbouded again. So what you need to do is refresh the browser tab by restarting the debug session in vscode and immediately after restarting pause it.
Then remove the unbound breakpoint and place it back again. After this the breakpoint is bound. Then resume the debug session and the breakpoint gets hit.
Quite some steps and not any better than using the debugger statement, but maybe this sheds some light on the issue...

Remote debugging C++ with VsCode

I have gdbserver attached to a process and working fine on a remote machine, port 9999. On my local machine, from command line:
$ gdb
(gdb) target remote localhost:9999
works just fine. I am trying to configure Vs Code debugger so that I can have a GDB frontend for this case. Here is my launch JSON.
"version": "0.2.0",
"configurations": [
{
"name": "GDB",
"type": "cppdbg",
"request": "attach",
"miDebuggerServerAddress": "localhost:9999",
"program": "path-to-cross-compiled-binary-with-same-debug-symbols",
"linux": {
"MIMode": "gdb",
},
}
]
There are couple of issues here. First of all, why "program"? In this case, gdb doesn't need any program name to start. Program is already running on remote, gdbserver is already attached to it. I just want gdb client to connect to port 9999. But anyways, moving on.
It wants me to give a processId. This also does not make sense, I am already attached on remote. The fun part is:
If you leave out processId, Vs Code says "unable to parse the process id"
If you specify a processId, Vs Code says "processId cannot be used with miDebuggerServerAddress"
Of course, if I am using a debugger server address, server is already attached to PID and it makes sense that processId can't be used in this case. But if I leave it out, VS Code gives the 1. error. This is cyclic in a way.
Anyone is able to attach to a remote process in VS Code C++ debugger with gdbserver address, that is my question. What is wrong with my launch file?
You need to use the "launch" request instead of "attach". I also needed to add the default "cwd" option.
"request": "launch",
"cwd": "${workspaceFolder}",
You may also need to define "additionalSOLibSearchPath".
My launch config now looks like this:
{
// 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": [
{
// "processId": "${command:pickProcess}",
"name": "(gdb) Remote Attach",
"type": "cppdbg",
"request": "launch",
"program": ".\\src\\binaryfolder\\app.nostrip",
"additionalSOLibSearchPath": "arm-none-linux-gnueabi/libc/lib;./lib;C:\\DeviceSDK\\win-2.8.15\\sdk\\toolchains\\arm-4.4.1\\arm-none-linux-gnueabi\\libc\\lib;C:\\DeviceSDK\\win-2.8.15\\sdk\\platforms\\201205\\lib",
// "processId": "${command:pickProcess}",
"MIMode": "gdb",
"cwd": "${workspaceFolder}",
"miDebuggerPath": "C:\\DeviceSDK\\win-2.8.15\\sdk\\toolchains\\arm-4.4.1\\bin\\arm-none-linux-gnueabi-gdb.exe",
"miDebuggerServerAddress": "192.168.205.88:51000",
"miDebuggerArgs": " -ex 'handle all print nostop noignore'",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true,
}
]
},
]
}
See CppTools issue 321

unable to start debugging unexpected gdb output from command environment cd

I want to lauch gdb in vscode. I want to debug my c code using gdb in vscode , but i m getting following error :
unable to start debugging unexpected gdb output from command environment cd
I have my gdb installed on wsl.
here is my lauch.json
{
// 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": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}\\bin\\main",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"pipeTransport": {
"pipeCwd": "",
"pipeProgram": "c:\\windows\\sysnative\\bash.exe",
"pipeArgs": ["-c"],
"debuggerPath": "/usr/bin/gdb"
},
"sourceFileMap": {
"/mnt/z": "z:\\"
}
}
]
}
I am unable to debug my program
Well, two years too late, but here we go.
From what I saw, you are using windows. I had the same problem and quickly resolved it. Apparently it's some system bug. To resolve, follow these steps:
(Tested on Windows 10)
Go to Windows Control Panel (You can do this by opening File Explorer and in the path type 'Control Panel' (without quotes) and hit Enter);
From the Control Panel, click on 'Clock and Region'.
Click Region. A new screen will open.
In the screen that opened, click on Administrative and search for the button "Change system location".
Check the option: "Beta: Use Unicode UTF-8 for world language support"
Restart the computer.
By doing this procedure, the problem will be solved.
I hope it has helped you and others who are experiencing this problem.

Visual Studio Code Task is Prepending the working directory to the command

I'm trying to setup visual studio code for rust to do debugging. In my launch.json file I have
{
"version": "0.2.0",
"configurations": [
{
"name": "(Windows) Launch",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceRoot}/target/debug/vscode-rust-debug-example.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true,
"preLaunchTask": "localcargobuildtask"
}
]
}
and in my tasks.json I have
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "localcargobuildtask",
"command": "echo hi",
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
Where "echo hi" is in my tasks I eventually want to have something like "cargo build" or "cargo test" or whatever. But this is just a starting step.
But when I press F5 the output I get is
> Executing task: C:\programs\VSCodeWorkspaces\RustProjects\vscode-rust-debug-example-debug-config-included\echo hi <
The terminal process terminated with exit code: 2
Terminal will be reused by tasks, press any key to close it.
Rather than running "echo" from where ever the terminal finds it (working directory first, then check global path variable like you would expect) it is actually looking for a program named "echo" in my root folder of the workspace.
How do I tell visual studio code "No I don't want you to run workspace/echo, I want you to run echo in workspace" ? Or is there another more direct way to tell visual studio code "compile this before you debug it" ?
The answer to this question How to debug Rust unit tests on Windows?
suggests that changing
"command": "cargo build",
into
"command": "cargo",
"args": [
"build"
],
in the tasks.json file works and somehow it does. Maybe the editor is configured to search the %path% for single word commands, or maybe some plugin I installed overwrote the "cargo" command. Maybe the reason echo wasn't found is because it is a terminal command, not a program. Maybe the error message was a lie and it was only reporting that it couldn't find workspacefolder\command despite checking %path%? Or maybe none of that. I have no idea. It is some pretty idiosyncratic behavior.

Terminate another task from within a postDebugTask - VS Code

I have a debug launch configuration (launch.json) like below.
{
"version": "0.2.0",
"configurations": [
{
"name": "Current TS File",
"type": "node",
"request": "launch",
"preLaunchTask": "Pre Debug Task",
"postDebugTask": "Stop Watch Styles",
"args": ["${relativeFile}"],
"runtimeArgs": ["--nolazy", "-r", "ts-node/register"],
"sourceMaps": true,
"cwd": "${workspaceRoot}",
"protocol": "inspector",
}
]
}
My tasks configuration (tasks.json) is like
{
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "next:copy",
"label": "Copy Files",
"problemMatcher": []
},
{
"type": "npm",
"script": "styles:tsw",
"label": "Watch Styles",
"problemMatcher": [],
},
{
"label": "Pre Debug Task",
"isBackground": true,
"dependsOn" :[
"Copy Files",
"Watch Styles"
]
},
{
"label": "Stop Watch Styles",
// No sure what should come here
}
]
}
Trying to stop watch process in postDebugTask, is there a way to Terminate Task by providing name (Watch Styles) as parameter in tasks.json. Watch styles is a continuously running process, please suggest if there is any other approach to terminate a task after debugging is complete.
This will terminate all tasks after debug stops
Or in this case, just build_runner watch...
launch.json
{
// 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": [
{
"name": "Flutter",
"request": "launch",
"type": "dart",
"flutterMode": "debug",
"preLaunchTask": "flutter: build_runner watch",
"postDebugTask": "Terminate All Tasks"
}
]
}
tasks.json
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "Terminate All Tasks",
"command": "echo ${input:terminate}",
"type": "shell",
"problemMatcher": []
}
],
"inputs": [
{
"id": "terminate",
"type": "command",
"command": "workbench.action.tasks.terminate",
"args": "terminateAll"
}
]
}
More info here: https://code.visualstudio.com/docs/editor/variables-reference#_command-variables
This works for me:
{
"label": "postdebugKill",
"type": "process",
"command":[
"${command:workbench.action.tasks.terminate}",
"${command:workbench.action.acceptSelectedQuickOpenItem}",
],
},
The first "${command:workbench.action.tasks.terminate}" will bring up a panel asking you to select which task to terminate. So if you had multiple running tasks and wanted to choose one you would use this command only.
The second "${command:workbench.action.acceptSelectedQuickOpenItem}" will terminate the selected task in that panel mentioned above. (So you will not even see the terminate panel.) If you have only one running task when you call the postdebugKill task, it will be selected automatically and thus terminated. Otherwise whichever task is listed first will be terminated. Again, if you have more than one other task running and you want to select which to terminate don't include this second command.
I don't know of any way to list, perhaps via an args option a label name for which task to terminate if running. It would be nice to have this functionality.
[postdebugKill name can be whatever you want.]
To call a postdebug task your launch.json config might look like this:
{
"type": "node",
"request": "launch",
"name": "Gulp: serve",
"program": "${workspaceFolder}/node_modules/gulp/bin/gulp.js",
"args": [
"serve"
],
// "preLaunchTask": "someTask",
"postDebugTask": "postdebugKill"
},
Upon stopping that "Gulp: serve" debugging session, the task "postdebugKill" will be triggered. And so if I had used the "preLaunchTask" to start a task or had simply started a task running before launching the "Gulp: serve" debugging session - that preLaunchTask would be terminated.
The ability to run vscode commands in a task was recently added to vscode. Some minimal info here: using a command in a task doc.
[I'll add another answer because the new additional info is extensive.]
It seems there is an issue with running a preLaunchTask and then launching a debugging session. See particularly debugging does not work on first try. It appears to be fixed though in an insiders edition and may be released in early February 2019. terminal not sending onLineData.
In the meantime there is a suggested fix within one of the issues that I have lost the link to and that is a problemMatcher which will signal to the debugger that the dependent tasks have completed.
In my watching task I used this:
"problemMatcher": [
{
"base": "$tsc-watch",
"background": {
"activeOnStart": true,
"beginsPattern": "Using gulpfile ~\\OneDrive\\experimental\\gulpfile.js",
"endsPattern": "Starting 'watch'..."
}
}
],
I chose that because when I manually start the gulp:watch task I get this in the terminal:
[22:27:48] Using gulpfile ~\OneDrive\experimental\gulpfile.js
[22:27:48] Starting 'watch'...
[22:27:48] Starting 'watch'...
So you see the start and end pattern there that I copied (with extra escaping).
I suggest that you separately run your "Pre Debug Task" and copy the start and ending output into your "Pre Debug Task" problemMatcher and see if it now works.
My code in the first answer I believe is correct, I just wasn't using "isBackground" and "dependsOn" as you are. But I have added "isBackground" to mine and the problemMatcher option and it works flawlessly now.
Hopefully, this will be fixed in the next February 2019 release and there will be no need for this workaround.
If on Linux or macOS, a less hacky solution that just works is using pkill. If on Windows, see below.
First run the task and find the full command vscode runs for that task, with $ ps -af
Then use pkill + the full command in a postDebugTask.
I have an entry in tasks.json like this:
{
"label": "stop npm:watch",
"type": "shell",
"command": "pkill -f 'sh -c node ./scripts/watch.js'",
"presentation": {
"reveal": "silent",
"panel": "dedicated",
"close": true,
}
}
'sh -c node ./scripts/watch.js' is how vscode runs my npm:watch task.
The presentation properties prevent this task from taking focus or taking up terminal space after it finishes successfully.
Then you reference that task in a launch.json configuration:
{
...
"preLaunchTask": "npm:watch",
"postDebugTask": "stop npm:watch",
...
}
If the full command contains changing parameters (paths, port numbers, etc.), you can use a part of the command or regex.
e.g.: I could have probably matched with './scripts/watch.js' or 'node.*watch'.
For Windows: you can make this work by substituting pkill for taskkill.
If you want to support both Unix and Windows, you can make a script that does one or the other depending on the underlying OS.