I suddenly am unable to run and compile any code in Vscide, When I try I get the following error message.
unable to find executable for '</home/dennis/Programs/cpp/'
The launch.json reads
{
// 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": "lldb",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/<executable file>",
"args": [],
"cwd": "${workspaceFolder}"
}
]
}
I am running linux mint 21.
It was working fine and then it suddenly stopped working. Something changed and I'm not sure what changed.
vscode about data.
Version: 1.73.0
Commit: 8fa188b2b301d36553cbc9ce1b0a146ccb93351f
Date: 2022-11-01T15:44:09.336Z
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Linux x64 5.15.0-52-generic
Sandboxed: No
Can some one help me.
I tried running previouslly ran code that worked in vscode and they suddenly do not work
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.
When I launch in VSCode dlv debug, I get this message:
User specified 'dlvLoadConfig' setting will be ignored by debug
adapter 'dlv-dap'.
Source is Go Nightly extension.
have dlvLoadConfig config section already become unavailable (obsolete)?
launch.json :
"configurations": [
{
"name": "Application Server",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/cmd/main.go",
"args": ["--config", "${workspaceFolder}/configuration/application.toml"],
"env": {
"CC":"/usr/bin/gcc",
"GOOS":"linux",
"GOARCH":"amd64",
"CGO_ENABLED":1
},
"dlvLoadConfig": {
"followPointers": true,
"maxVariableRecurse": 1,
"maxStringLen": 1024,
"maxArrayValues": 64,
"maxStructFields": -1
},
"trace": "log"
// "buildFlags": "-tags dev -ldflags '-X main.BuildDate=2021-04-28T19:38:16+03:00'"
}
]
You might need to update your configuration as mentioned here:
https://github.com/golang/vscode-go/blob/master/docs/debugging.md#switching-to-legacy-debug-adapter
https://github.com/golang/vscode-go/blob/master/docs/debugging.md
(from :https://github.com/golang/vscode-go/blob/master/docs/dlv-dap.md )
"go.delveConfig": {
"debugAdapter": "legacy",
}
On a side note, installing the latest didn't seem to copy the binary as dlv-dap (which seems to be expected by vscode) I just created a sym link to dlv (mac-osx), and it works in dlv-dap mode
ln -s dlv dlv-dap
Adding "debugAdapter" works for me too.
"debugAdapter": "legacy",
https://github.com/golang/vscode-go/blob/master/docs/debugging.md#settings
The new dlv-dap takes a completely different approach in loading data, so dlvLoadConfig is no longer necessary.
For string values, it uses 512 or 4K depending on the context as of Aug 2021. (512 for display in the VARIABLES section, 1K for function call results, 4K if you query the variables from the DEBUG CONSOLE or use COPY VALUE)
I noticed you were using maxStringLen: 1024 in your settings. We are currently considering to increase the limit of how much we show in the VARIABLES section. We are increasing this slowly and conservatively because it causes loading a lot of data for all variables automatically and it can slow down the debugging performance. If inspecting long string variables from DEBUG CONSOLE (on demand) is not sufficient, please open a new issue in the github.com/golang/vscode-go repo.
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
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 :).