Unable to start debugging. GDB exited unexpectedly with exit code 134 (0x86) - macos

I'm trying to use the gdb debugger on macOS BigSur (11.4) without any success. I always get the same error : Unable to start debugging. GDB exited unexpectedly with exit code 134 (0x86), even though I tried to create a certificate and sign it (like this : https://www.ics.uci.edu/~pattis/common/handouts/macmingweclipse/allexperimental/mac-gdb-install.html), and I tried to enable debugging with the command csrutil enable --without debug (like this : https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d).
I'm using that launch.json file :
{
// 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",
"type": "cppdbg",
"request": "launch",
"program": "/Users/felix/projects/artn_abinitio/build/artn.x",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "/usr/local/bin/gdb",
}
]
}
I'm using VsCode : Version: 1.58.0-insider (Universal).
If you have another idea.
Thank you!

Related

Unable to debug a TypeScript testing framework using Visual Studio Code

I am not able to get debugging working on VSCode for a testing framework using WebdriverIO . Only this message is displayed: - Waiting for the debugger to disconnect.
However, I am able to get debugging up and running for a TS code one time. If I am starting my machine once, and then again, it is giving same issue as - Waiting for the debugger to disconnect.
Below is the launch.json file:
{
// 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",
"skipFiles": [
"<node_internals>/**"
],
"outputCapture": "std",
"name": "Launch Program",
"program": "${workspaceRoot}/node_modules/#wdio/cli/bin/wdio.js",
"args": ["${workspaceRoot}/build/main/config/wdio.conf.js"],
"preLaunchTask": null,
"sourceMaps": true,
"outFiles": [
"${workspaceFolder}/out/**/*.js"
],
"resolveSourceMapLocations": [ //code to avoid 'Could not read sourcemaps' issues
"${workspaceFolder}/**",
"!**/node_modules/**"
]
}]
}
Console-log stack-trace:
C:\Program Files\nodejs\node.exe .\node_modules#wdio\cli\bin\wdio.js
C:\Automation\angular_ui-auto-framework/build/main/config/wdio.conf.js
Debugger attached.   Execution of 1 workers started at
2022-12-21T15:25:32.199Z   [2022-12-21 20:55:32:902] - DONE - File
'c:\Automation\angular_ui-auto-framework\src\osr_ui-automation\Results\testReport.json'
is deleted successfully    Waiting for the debugger to disconnect...
I have faced similar problems with latest version of the vscode. I had to downgrade to nodejs 16lts and downgrade vscode to 1.57 and using below launch.json working fine so far.
{
"name": "Start Spec",
"type": "node",
"request": "launch",
"args": ["wdio.conf.js", "--spec", "${file}"],
"cwd": "${workspaceFolder}",
"autoAttachChildProcesses": true,
"program": "${workspaceRoot}/node_modules/#wdio/cli/bin/wdio.js",
"console": "integratedTerminal"
}

lldb not working with VS Code on Mac - outDebug file

I'm new to VS Code. I got debugging with lldb working--for one day it worked great.
Then it began to malfunction, displaying the arrow several source statements away from the actual execution. I've tried several config changes using online guidance to no avail. I thought that maybe the debug database was messed up so I wanted to try to get it to regenerate, so moved the outDebug file aside. That did not cause it to be rebuilt.
I'm running this launch.json configuration:
{
"name": "(lldb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/rmv_ms",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "lldb",
"miDebuggerPath": "/usr/bin/lldb",
"preLaunchTask": "clang build active file"
},
and this in tasks.json:
"tasks": [
{
"label": "clang build active file",
"type": "shell",
"command": "/usr/bin/clang",
"args": [
"-std=c17",
"-stdlib=libc++",
"-g",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"options": {
"cwd": "${workspaceFolder}"
},
"group": { "kind":"build", "isDefault":true },
"presentation": {
// Reveal the output only if unrecognized errors occur.
"reveal": "silent"
},`enter code here`
// Use the standard MS compiler pattern to detect errors, warnings and infos
"problemMatcher": "$gcc"
}
]
The latest behavior is that when I try to start debug session it displays a menu asking me what to attach to (whatever that means) but I don't even see my program listed.

Can't debug Golang with breakpoints in VSCode

I debug Golang application with breakpoints in VS Code.
Debugger complains that can't find file, which exists.
Does anyone of you know how to enable breakpoints for Go application in VS Code?
Debugger logs:
Debuggee is not running. Setting breakpoints without halting.
All cleared
Creating on: /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go:63
Creating on: /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go:84
All cleared
All set:[]
SetBreakPointsResponse
2021-10-21T12:52:17+02:00 debug layer=rpc <- RPCServer.CreateBreakpoint(rpc2.CreateBreakpointIn{"Breakpoint":{"id":0,"name":"","addr":0,"addrs":null,"file":"/home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go","line":63,"Cond":"","HitCond":"","continue":false,"traceReturn":false,"goroutine":false,"stacktrace":0,"LoadArgs":{"FollowPointers":true,"MaxVariableRecurse":1,"MaxStringLen":64,"MaxArrayValues":64,"MaxStructFields":-1},"LoadLocals":{"FollowPointers":true,"MaxVariableRecurse":1,"MaxStringLen":64,"MaxArrayValues":64,"MaxStructFields":-1},"WatchExpr":"","WatchType":0,"hitCount":null,"totalHitCount":0,"disabled":false}})
2021-10-21T12:52:17+02:00 debug layer=rpc -> *rpc2.CreateBreakpointOut{"Breakpoint":{"id":0,"name":"","addr":0,"addrs":null,"file":"","line":0,"Cond":"","HitCond":"","continue":false,"traceReturn":false,"goroutine":false,"stacktrace":0,"LoadArgs":null,"LoadLocals":null,"WatchExpr":"","WatchType":0,"hitCount":null,"totalHitCount":0,"disabled":false}} error: "could not find file /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go"
2021-10-21T12:52:17+02:00 debug layer=rpc <- RPCServer.CreateBreakpoint(rpc2.CreateBreakpointIn{"Breakpoint":{"id":0,"name":"","addr":0,"addrs":null,"file":"/home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go","line":84,"Cond":"","HitCond":"","continue":false,"traceReturn":false,"goroutine":false,"stacktrace":0,"LoadArgs":{"FollowPointers":true,"MaxVariableRecurse":1,"MaxStringLen":64,"MaxArrayValues":64,"MaxStructFields":-1},"LoadLocals":{"FollowPointers":true,"MaxVariableRecurse":1,"MaxStringLen":64,"MaxArrayValues":64,"MaxStructFields":-1},"WatchExpr":"","WatchType":0,"hitCount":null,"totalHitCount":0,"disabled":false}})
2021-10-21T12:52:17+02:00 debug layer=rpc -> *rpc2.CreateBreakpointOut{"Breakpoint":{"id":0,"name":"","addr":0,"addrs":null,"file":"","line":0,"Cond":"","HitCond":"","continue":false,"traceReturn":false,"goroutine":false,"stacktrace":0,"LoadArgs":null,"LoadLocals":null,"WatchExpr":"","WatchType":0,"hitCount":null,"totalHitCount":0,"disabled":false}} error: "could not find file /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go"
2
Error on CreateBreakpoint: could not find file /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go
File exists:
gbajson#misio:~$ ls -l /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go
-rw-r--r-- 1 gbajson gbajson 2961 Oct 21 12:22 /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go
I already checked that it's not a problem with file permissions.
I also followed up the procedure for the lagacy version of dlv:
https://github.com/golang/vscode-go/blob/master/docs/debugging-legacy.md#selecting-legacy-debug-adapter
Debugger configuration
workspace.code-workspace
"launch": {
"version": "0.2.0",
"configurations": [
{
"name": "Debug Go",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${fileDirname}",
"debugAdapter": "legacy",
"env": {},
"args": [],
"showLog": true,
"logOutput": "rpc",
"trace": "log"
},
settings.json
{
"go.delveConfig": {
"debugAdapter": "legacy",
},
I found the problem. VS Code doesn't handle symbolic links well.
When I set up a project in VS Code in real path debugger started to work properly.
gbajson#misio:~$ realpath /home/gbajson/Sync/clickr/clickr-node-api/clickr-node-api.go
/storage/amoje/Sync/clickr/clickr-node-api/clickr-node-api.go
This problem is also described in: https://github.com/golang/vscode-go/issues/1677
Wanted to share my solution here.
After reading a few github issues vs-code-go, seems like the issue was a result of remotePath or substitutePath. After a few attempts, setting remotePath to "" finally did the trick.
"version": "0.2.0",
"configurations": [
{
"name": "Connect to server",
"type": "go",
"request": "attach",
"mode": "remote",
"remotePath": "",
"port": 40000,
"host": "<host>",
}
]
}
This is a follow-on from the answer by gbajson.
Symbolic links were the problem for me. Using this configuration in launch.json resolved the issue, while allowing me to keep my symlinks:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/cmd/server/main.go",
"envFile": "${workspaceFolder}/.env",
"substitutePath": [
{
"from": "/home/me/go-workspaces",
"to": "/data/projects/workspaces"
}
]
}
]
}
Specifically, it is the "substitutePath" part.
My workspace directory was actually symlinked from "/home/me/go-workspaces" to the real directory "/data/projects/workspaces".
See: https://github.com/golang/vscode-go/blob/master/docs/debugging.md#debugging-symlink-directories
You can use "sudo ps aux | fgrep {your process name}" to check your process.If it start more than 1 process, maybe you should change your process start mode without daemon process.

Is it possible to print to a clear integrated terminal in VSCode

I want the output from my program to be printed on an empty terminal. ie, instead of,
PS C:\Stuff\More Stuff> & 'c:\Users\user\.vscode\extensions\ms-vscode.cpptools-1.4.1\debugAdapters\bin\WindowsDebugLauncher.exe' '--stdin=Microsoft-MIEngine-In-w1d2d2zg.skd' '--stdout=Microsoft-MIEngine-Out-2q3w4dx4.xne' '--stderr=Microsoft-MIEngine-Error-sr0qr1un.pod' '--pid=Microsoft-MIEngine-Pid-zddzumbv.aaf' '--dbgExe=C:\Program Files\CodeBlocks\TDM-GCC-64\bin\gdb.exe' '--interpreter=mi'
Hello from my program
I want,
Hello from my program
Here is my launch.json if it's of any help,
{
// 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": "g++.exe - Build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}\\${fileBasenameNoExtension}.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:\\Program Files\\CodeBlocks\\TDM-GCC-64\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "C/C++: g++.exe build active file"
}
}
So, is there a way to output the program into an empty terminal?
Edit: I found a similar question here, but the solution posted doesn't work for me. It says, "Property console is not allowed". I am using the f5 debugger to run my C++ programs. I found some other similar questions, but they don't have an answer.
For now, the best working solution I could find is running the following command at the start of the program.
int main()
{
cout << "\033[2J\033[1;1H";
/*rest of the code here*/
}
This clears the terminal before execution of the actual program. This will also clear any outputs from previous runs. I'd prefer to have my previous outputs.

VSCode debugging C++ launches external terminal, but doesn't run program

I've set up a launch.json file such that a C++ program uses an external console (so that it can receive user inputs), but when launching, VSCode simply opens a terminal window without running the program in it. If "externalConsole": true, is set to false, the program runs and can be debugged fine, just can't take inputs.
Note: No task.json file is used, CMake is used to create the executable binary.
Launch file:
{
// 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": "g++ - Debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/bin/program_bin",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build/bin",
"environment": [],
"MIMode": "lldb",
"externalConsole": true,
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true,
}
]
}
]
}
Is it possible that VSCode doesn't have 'permission' to run an external terminal? Using on MacOS.
I have the same issue. This may not be the working answer, but hopefully it will get us farther down the correct path.
I did some digging and found the following:
VS Code Documentation mentioned that it opens an external console via lldb-mi.
A search for lldb-mi led to this post on the Apple Developer forums.
...which leads to an open source Github Repo with a build of lldb-mi
I need to read through the documentation for that build first, and then I'll give it a shot. I'll post results if it solves the issue.
I've tried to use standard (recomended ways of debugging from vscode documentation) and ran into the same issues with external terminal.
I'm also using mac and switching to CodeLLDB plugin to use LLDB for debugging helped
https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb
just follow documentation: https://github.com/vadimcn/vscode-lldb/blob/v1.8.1/MANUAL.md
But as a hint here is my working setup:
(I couldn't though make it work on windows, but I'm running windows via Parallel II, so maybe natively this plugin will work too)
tasks.json
{
"tasks": [
{
"type": "cppbuild",
"label": "C/C++: clang build active file",
"command": "/usr/bin/g++",
"args": [
"-fcolor-diagnostics",
"-fansi-escape-codes",
"-g",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}.exe"
],
"options": {
"cwd": "${fileDirname}"
},
"problemMatcher": ["$gcc"],
"group": {
"kind": "build",
"isDefault": true
},
"detail": "Task generated by Debugger."
}
],
"version": "2.0.0"
}
launch.json
{
"configurations": [
{
"name": "(lldb) Launch",
"type": "lldb",
"request": "launch",
"program": "${fileDirname}/${fileBasenameNoExtension}.exe",
"args": [],
// "stdio": ["input.txt", null, null], // https://github.com/vadimcn/vscode-lldb/blob/v1.8.1/MANUAL.md#stdio-redirection
"cwd": "${fileDirname}",
"preLaunchTask": "C/C++: clang build active file" // this have to be the same as "label" in tasks.json
}
],
"version": "2.0.0"
}
just make sure you have all tools available, check by running in cli:
/usr/bin/clang --version
# and
lldb --version
good luck

Resources