10

I am trying to use GDB to run the debugger in VSCode in a C++ project, but I keep getting this error when running my debugger. I have set up a cert and everything and it is still giving me this error (I am running macOS Catalina version 10.15.4).

Here is my 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) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/Assignment8",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}

Here is my tasks.json file

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "make",
            "options": {
                "cwd": "${workspaceFolder}/build"
            },
        }
    ]
}

Additionally, I saw something about making a .gdbinit file, which I did in my root directory, and I placed the following command in it:

set startup-with-shell off

Any help with this issue would be greatly appreciated.

Nathan Anderson
  • 155
  • 1
  • 2
  • 7

7 Answers7

4

I had same problem too. More or less this:

ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Error creating process /usr/bin/, (error 2).

To fix please try to use lower versions of gcc / g++ (v_9 or so) and specially lower version of gdb ( v_10, experimental version installed was the problem, changed to 9.3 and Ok).

Juan Pedro Uya
  • 41
  • 3
2

The "program" parameter in your launch.json should be the path of your debuggable executable.

I'm guessing that you are using g++. Your program will be debuggable if you use the -g switch. Thus your compilation will be

g++ -g path/to/prog.cpp -o a.out

This will make a debuggable executable file as "a.out".

Make sure your "program" parameter is pointing to this file. Considering this file is generated at the root of your workspace, you'll need to have it set as

"program": "${workspaceFolder}/a.out

I hope you are following all there steps.

AzuxirenLeadGuy
  • 2,470
  • 1
  • 16
  • 27
2

In my case, this problem seems to be directly related to gdb 10.2-1. Downgrading gdb to 9.2-1 solved the problem instantly.

David Vancina
  • 141
  • 2
1

I got a problem similar. The problem was that a folder had an accent (´) on its name, like path/to/elétron. The solution was remove the accent. To path/to/eletron.

Natã Santos
  • 19
  • 1
0

Try this stucture of files

> SomeFolder   
  > .vscode    
    - tasks.json    
    - launch.json  
> MainFolder   
    - main.cpp    
    - main.exe

launch.json

    "version": "0.2.0",
"configurations": [
    {
        "name": "DEBUG",
        "type": "cppdbg",
        "request": "launch",
        "program": "${fileDirname}\\${fileBasenameNoExtension}.exe",
        "args": [],
        "stopAtEntry": false,
        "cwd": "${workspaceFolder}",
        "environment": [],
        "externalConsole": false,
        "MIMode": "gdb",
        "miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
        "setupCommands": [
            {
                "description": "gdb",
                "text": "-enable-pretty-printing",
                "ignoreFailures": true
            }
        ],
        "preLaunchTask": "C/C++: g++.exe build active file"
    }
]

}

tasks.json

{
"tasks": [
    {
        "type": "shell",
        "label": "C/C++: g++.exe build active file",
        "command": "C:\\MinGW\\bin\\g++.exe",
        "args": [
            "-g",
            "${file}",
            "-o",
            "${fileDirname}\\${fileBasenameNoExtension}.exe"
        ],
        "options": {
            "cwd": "${workspaceFolder}"
        },
        "problemMatcher": [
            "$gcc"
        ],
        "group": {
            "kind": "build",
            "isDefault": true
        }
    }
],
"version": "2.0.0"

}

Maddocrus Mad
  • 1
0

Update November 2022

I tried the downgrading option described in earlier answers but to no avail. It turns out the issue is caused by the fact that the Darwin kernel in more recent versions of macOS restricts the ability of a process to assume control of another process, which is exactly what the gdb debugger must do.

The solution is to code-sign your gdb binary.

See https://sourceware.org/gdb/wiki/PermissionsDarwin for instructions on how to do this.

Note: Installing gdb using brew actually warns you about this requirement now. The following extract is embedded in the messages printed after an install and references the very same URL.

==> Caveats
gdb requires special privileges to access Mach ports.
You will need to codesign the binary. For instructions, see:

  https://sourceware.org/gdb/wiki/PermissionsDarwin

Credit: This issue is also discussed on the Visual Code GitHub forum here, which is where I found the solution link to the GDB wiki.

Donnacha
  • 61
  • 1
  • 5
0

I had a similar issue with GDB 12.1 on Ubuntu 22.04. Sounds like there's a long standing issue with WSL not supporting /proc/*/mem files, and GDB insisting on it.

Not sure when a long term solution would be in place (probably needs to come from the gdb team), but this post describes the hack that gave me near term relief.

echo -en '\x90\x90' | sudo dd of=/usr/bin/gdb count=2 bs=1 conv=notrunc seek=$((0x335C7D))

This command edits the gdb binary to ignore the fact that it cannot find /proc//mem (since ptrace does the job fine enough).

Please note that this "hack" is binary dependent - it wouldn't work on another version of gdb.

Dr Phil
  • 430
  • 5
  • 17