I am trying to debug an open-source C code with MPI. This open-source has it own Cmakefile. I enable the mpi and debug model with the instructions of the open-source in the terminal. After the executable file named gmx_mpi is created, I import the project to visual studio code. I can run the executable file in terminal with below command
mpirun -np 4 gmx_mpi mdrun -s diff.tpr -c diff.gro -ntomp 1
So I made below configurations to debug the code with MPI in the visual studio code.
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "/usr/bin/mpirun",
"args": [
"-np",
"4",
"/home/fanli/workspace/gromacs_fh_debug/build/bin/gmx_mpi",
"mdrun",
"-s",
"diff.tpr",
"-deffnm",
"diff",
"-ntomp",
"1"
],
"stopAtEntry": false,
"cwd": "/home/fanli/workspace/protein_water/double/40ms",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
However, the code did not stop at the breakpoint I set, instead it run directly as if the it is in the release mode.
I googled a lot but did not find the solution.
Could anyone tell me how to debug the MPI code in visual studio code.
Currently, you cannot debug MPI code in vs code automatically and there is no extension to do so. See the issue below on GitHub for any change or update
GitHub
However, I found a workaround to duplicate the vs code window and attach the debugger manually:
YouTube
Related
I am trying to work in VSCode 1.76.0-insiders on Windows 10 and what happens is that GO v1.20 compiler for some reason compile the application to temporary (?) folder - this action blocked by antivirus.
Could you suggest what settings I need to set in launch.json to compile into the same folder where source code is ?
Here is output of 'Debug console'
Starting: C:\Users\user01\go\bin\dlv.exe dap --only-same-user=false --listen=127.0.0.1:56552 from C:\projects\go.tfs-exporter
DAP server listening at: 127.0.0.1:56552
Build Error: go build -o C:\projects\go.app\__debug_bin.exe -gcflags all=-N -l .
tfs-exporter: go build go.app: open C:\Temp\go-build2738799206\b001\exe\a.out.exe: Access is denied. (exit status 1)
you see this strange folder: C:\Temp\go-build2738799206\b001\exe\a.out.exe ?? This is automatically blocked - no questions asked
here is my launch.json file:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Package",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}",
"dlvFlags": [
"--only-same-user=false"
]
}
]
}
or any other suggestion on how to configure GO compiler with Antivirus in corporate environment ?
https://community.bitdefender.com/en/discussion/84185/false-positive-when-running-go-lang-program-edited-in-visual-studio-code
As advised here https://forum.golangbridge.org/t/bitdefender-detects-output-as-a-virus/22152/8 a "good" solution would be to add the environment variable GOTMPDIR with any path of your choice, where the builds are going to be stored. (Maybe reboot after this)
Then just go to BitDefender Protection -> Antivirus -> Settings -> Manage Exceptions and add your path as an exception.
I'm trying to run from a launch.json file, so i can use gdb to debug my program in vscode.
The launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "g++ build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "SourceFolder/test",
"args": [],
"stopAtEntry": false,
"cwd": "SourceFolder",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "g++ compile active file",
"miDebuggerPath": "/usr/bin/gdb"
}
]
}
The path is correct, i can see the compiled file right there in the folder.
I can run the program via console (bash) no problem and it doesn't throw any errors, but when i run it via this method i get the following pop up:
Unable to start debugging. Program path 'SourceFolder/test' is missing or invalid.
GDB failed with message: SourceFolder/test: File or directory not found.
...
And the debug-terminal returns:
The program 'SourceFolder/test' has exited with code 42 (0x0000002a).
Could "preLaunchTask": "g++ compile active file" be causing this error?
The preLaunchTask name must match the label tag of the tasks.json file built by default in .vscode. Check they match.
If this isn't enough, go on your source code file, press Ctrl+Shift+B and see if the precompiler does everything fine. You should see something like this:
> Executing task: g++ build active file <
Starting build...
/usr/bin/g++ -fdiagnostics-color=always -g "sourcefilename.extension" -o "sourcefilenameNoExtension"
Build finished successfully.
Terminal will be reused by tasks, press any key to close it.
If this happens to be fine then you should have the file 'SourceFolder/test' ready to run. If this went wrong you may check your tasks.json settings or simply change the filename to be test.extension and put it in the SourceFolder folder if you didn't yet.
If you meant the SourceFolder to be the default value for the actual opened folder then you should have write ${workspaceFolder}.
By the way you can find this and more in this guide by VSCode
https://code.visualstudio.com/docs/languages/cpp#_tutorials
Here you'll find links to use G++ on your operating system.
Golang: 1.15
Visual Studio Code: 1.49.1
The Go program is rendering a Console User Interfaces with gocui, and requires a dedicated terminal to run correctly.
Q: how to build the program, start it up in a terminal and debug it with the VSC?
Build the program with debug flags:
go build -gcflags="all=-N -l" -o $(BUILD_PATH)
Add following configuration to your VSC:
{
"name": "Connect to dlv server",
"type": "go",
"request": "attach",
"mode": "remote",
"remotePath": "${workspaceFolder}",
"port": 2345,
"host": "127.0.0.1"
},
Start up the compiled program via debugger
NOTE: dlv is an official Go debugger, installed along with the Go SDK
dlv --listen=:2345 --headless=true --api-version=2 --accept-multiclient exec {YOUR_PROGRAM}
Chose "Connect to dlv server" from the Debug view and happy debugging!
I was trying to setup debug configuration to attach to already running gdbserver.
(ref used: https://code.visualstudio.com/docs/cpp/launch-json-reference)
[Note. I can attach and debug with an arch specific gdb instance fine to the gdbserver]
That's the template that has logic check deadlock.
{
"name": "(gdb) Attach to gdbserver in QEMU",
"type": "cppdbg",
"request": "attach",
"MIMode": "gdb",
"miDebuggerPath": "/path/to/gdb/../../bin/mips-mti-linux-gnu-gdb",
"miDebuggerServerAddress": "localhost: 1234",
"program": "${workspaceFolder}/__out--MIPS64r6_MTI/vmlinux",
// "processId": "${command:none}",
// "processId": "${command:pickProcess}",
// "processId": "23739",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
When no "processId" given, it complains:
unable to parse process id
When some valid "processId" given (and then some process also selected from the list, if demanded by UI), it complains:
'processId' cannot be used with miDebuggerServerAddress
Does anyone know how to resolve this deadlock in VC debug config parsing logic or this is a bug?
Thank you.
Ok. After several tries it worked ;)
Using the "request": "launch" (despite sounds a bit illogical, as we're attaching to already running process, just supplied with gdbserver i-face) without "processId" as advised in #577 bug discussion, the DB session was braking up initially with complain:
remote replied unexpectedly to 'vMustReplyEmpty': timeout, but eventually worked after repeated tries ;)
Note. For "lanuch" case, VC demanded also adding: "cwd": "${workspaceRoot}"
The VC+CPP-plugin support needs updating the instructions then (https://code.visualstudio.com/docs/cpp/launch-json-reference).
It sounds really illogical to use "request": "launch" to actually do the attach action :).
I am using VSCode, writing code for a RPi. I have almost gotten it set up to use the integrated debugger, however, I am running into an issue where GDB says Command Aborted
Here is the ouput from the debug window in VSCode
<License and whatnot from GDB>
=cmd-param-changed,param="pagination",value="off"
Reading /lib/ld-linux.so.3 from remote target...
Reading /lib/ld-linux.so.3 from remote target...
Reading /lib/f72fb00897d4f06093d6f0451c9ca7d1f6e14c.debug from remote target...
Reading /lib/.debug/f72fb00897d4f06093d6f0451c9ca7d1f6e14c.debug from remote target...
0x76fce9e0 in ?? () from target:/lib/ld-linux.so.3
Loaded 'target:/lib/ld-linux.so.3'. Symbols loaded.
ERROR: Command aborted.
Here is the script I am using to setup gdbserver on the RPi (with the variable names excluded to protect my privacy).
ssh \
-L$port:localhost:$port $user#$remote \
"zsh -l -c './kill-gdbserver.sh && cd msat-pi* && ./waf && gdbserver :$port ./build/examples/onewire/onewire'"
And the relevant configuration from my launch.json
{
"name": "1w-Remote",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/build/examples/onewire/onewire",
"miDebuggerServerAddress": "localhost:8081",
"targetArchitecture": "arm",
"args": [],
"miDebuggerPath": "/usr/bin/gdb-arm",
"preLaunchTask": "waf-build",
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true,
"linux": {
"MIMode": "gdb"
},
"osx": {
"MIMode": "gdb"
},
"windows": {
"MIMode": "gdb"
}
}
If I manually setup GDB locally, I get the same output, except, no Command Aborted message. I can then continue, which acts as I would expect (my program crashes on an unhandled exception).
Is there some way I can avoid this Command Aborted issue, or should I open an issue on the VSCode git?
Thank you
You have compiled your program without debugging information. Compile it with -g compiler and linker option.