GDB is unable to open/attach to Rack

Development
1

I’m encountering a very vague problem.

Whenever I attempt to attach GDB to Rack in order to debug, I get the following error:

ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited with code 0xc0000135.
The program 'C:\SDKs\Rack\Rack.exe' has exited with code 0 (0x00000000).

I am attempting to start an instance of Rack compiled from source and started in developer mode, and all of this works fine, so long as I don’t attempt to launch with debug.

My tasks.json code for debug looks as follows:

      {
        "label": "Build application without stripping symbols and add to Rack plugin folder",
        "type": "shell",
        "command": "make ARGS=\"no-strip\" install",
        "options": {
          "cwd": "${workspaceRoot}",
          "env":{
              "PATH": "C:/msys64/usr/bin/;C:/msys64/mingw64/bin",
              "RACK_DIR": "C:/SDKs/Rack-SDK/"
          }
        },
        "group": {
          "kind": "build",
          "isDefault": true
        },
        "presentation": {
          "echo": true,
          "reveal": "always",
          "focus": false,
          "panel": "shared"
        },
        "problemMatcher": {
          "owner": "cpp",
          "fileLocation": ["absolute"],
          "pattern": {
              "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
              "file": 1,
              "line": 2,
              "column": 3,
              "severity": 4,
              "message": 5
          }
        }
      },

The “no-strip” line causes plugin.mk to skip stripping when building.

My launch task looks as follows:

      {
        "name": "Launch Debug",
        "type": "cppdbg",
        "request": "launch",
        "program": "C:/SDKs/Rack/Rack.exe",
        "args": ["-d"],
        "stopAtEntry": false,
        "cwd": "C:/SDKs/Rack/",
        "environment": [],
        "externalConsole": false,
        "MIMode": "gdb",
        "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe",
        "preLaunchTask": "Build application without stripping symbols and add to Rack plugin folder",
        "setupCommands": [
            {
                "description": "Enable pretty-printing for gdb",
                "text": "-enable-pretty-printing",
                "ignoreFailures": true,
            }
        ]
      }

For reference: “C:/SDKs/Rack/” is the Rack sourcecode and build, while “C:/SDKs/Rack-SDK/” is the Rack SDK. My workspace is “C:/SDKs/Rack-SDK/TestPlugin”.

When encountering this, Rack produces no log file, and even turning on logging for gdb gives me absolutely nothing. Extensive google searches also gives me nothing.

My environment successfully builds the tutorial plugin, the Fundamental library, and Rack itself, so I’m pretty confident that all of the underlying programs and dependencies are functioning correctly.

However, this one has me completly stumped. I have no idea where to look for potential errors.

I have some feeling that it might be a path problem somehow, but I have no idea how to figure out how or where.

The PC is running Windows 11 Pro.

Has anyone encountered anything similar?

2

Update: I’m seeing the following in the debug console, before the error:

[New Thread 7576.0x18f0]
[New Thread 7576.0x3bec]
[New Thread 7576.0x3444]
[Thread 7576.0x4bbc exited with code 3221225781]
[Thread 7576.0x18f0 exited with code 3221225781]
[Thread 7576.0x3bec exited with code 3221225781]

Investigation shows that this means that a dll is missing or unreachable, further reinforcing my path problem theory.

3

Okay, so I’ve figured out what the problem is, but I am uncertain as for how to solve it.

VSCode, when using the cppdbg “type” parameter, launches the default terminal, which in this case points to the MinGW64. This is verified as when I change the default integrated terminal, the terminal that attempts to launch the debugger also changes.

However, when the debugger attempts to launch MinGW64, for some strange reason, it instead launches Msys. This does not happen if I manually start a new default terminal, only when the debug configuration attempts to start a new default terminal.

And sure enough, if I attempt to start rack.exe with this Msys terminal, it is unable to locate librack.dll, and promptly crashes. Attempting the same on MinGW64 works perfectly fine.

So the issue is that the debugger starts the wrong MinGW shell, for some reason. Does anyone have any insight on how I can configure this?

image
image935×64 2.87 KB

The REALLY strange thing is that if I manually start an Msys terminal outside of VSCode, it opens rack.exe no problem. It’s just this specific, rogue terminal that seems to not give a damn about anything.

4

tried this?

5

Yep, tried and followed everything that is written there to no avail.

My current theory is that for some reason, VSCode fails to pass on env arguments when starting the console with “cppdbg” as type.

6

Not tried this myself. HTH

7

Okay, so I’m making progress. Turns out that the debugger was pulling the environment settings from the non-local setting.json file. Adding the terminal to my user settings instead of my workspace settings solved the problem, and the debugger now correctly starts MinGW64, which correctly initializes the debugger.

However, the debugger seems…half-functional? Breakpoints work, so long as they are added before starting debugging. However, I am unable to deactivate breakpoints during debugging. They stay loaded regardless. Finally, the pause execution button does not work. At all.

8

This is normal for some debuggers (notably those based on GDB) on Windows. The debugger can’t control the debuggee while it’s executing, only when it’s paused. Pressing the F12 key when the debuggee is active will pause the process. That’s how you break into the process, and that’s when you can then control breakpoints.

9

But that’s the thing: F12 / Pause doesn’t work.

10

Ah, sorry, I don’t know what’s going on there. :frowning: