`cppdbg` / MIEngine loses debugger control with `gdb 17.1` in Linux dev container, while `gdb 16.2` works

[rastocny]

Summary

In a Linux VS Code dev container, cppdbg with MIMode: "gdb" starts gdb 17.1 and launches the inferior process, but VS Code never gains usable debugger control.

Observed behavior with gdb 17.1:

• The debuggee process starts.
• The VS Code debugger UI does not become operational.
• Pause does not work.
• The session does not finish normally.
• In practice the gdb process must be killed manually.

The same setup works when either of these is true:

• cppdbg uses gdb 16.2
• the WebFreak GDB adapter is used instead of Microsoft cppdbg

That strongly suggests an MIEngine compatibility issue with gdb 17.1, rather than a generic container TTY or ptrace problem.

Environment

• Host workflow: VS Code connected to a Linux dev container
• VS Code version: 1.128.0
• OS inside container: Ubuntu 26.04 (Resolute Raccoon)
• gdb failing with cppdbg: GNU gdb (Ubuntu 17.1-2ubuntu1) 17.1
• gdb working with cppdbg: GNU gdb (GDB) 16.2
• GCC in container: gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0
• VS Code extensions in container:
  • ms-vscode.cpptools 1.32.2-linux-x64
  • ms-vscode.cpp-devtools 0.5.13
  • ms-vscode.cmake-tools 1.23.52
  • webfreak.debug 0.27.0
  • vadimcn.vscode-lldb 1.12.2

Container run arguments:

[
  "--network=host",
  "--cap-add=SYS_PTRACE",
  "--security-opt=seccomp=unconfined",
  "--security-opt=apparmor=unconfined"
]

Relevant container facts already checked:

• /dev/pts is mounted and usable
• tty returns a valid pseudo-terminal
• kernel.yama.ptrace_scope = 1
• NoNewPrivs: 0

Minimal repro configuration

This reproduces with a standard cppdbg launch configuration using MIMode: "gdb":

{
  "name": "Linux Debug",
  "type": "cppdbg",
  "request": "launch",
  "program": "/path/to/test-binary",
  "cwd": "/path/to/workspace",
  "externalConsole": false,
  "MIMode": "gdb",
  "miDebuggerPath": "/usr/bin/gdb",
  "setupCommands": [
    {
      "description": "Enable pretty-printing for GDB.",
      "text": "-enable-pretty-printing",
      "ignoreFailures": true
    },
    {
      "description": "Disable debuginfod prompts.",
      "text": "-gdb-set debuginfod enabled off",
      "ignoreFailures": true
    }
  ]
}

The same configuration works after changing only:

"miDebuggerPath": "/opt/gdb-16.2/bin/gdb"

Observed behavior

With gdb 17.1:

• VS Code starts gdb.
• The inferior process is started.
• The debugger does not attach in a usable way from the VS Code side.
• Pause is non-functional.
• The session remains stuck until gdb is killed.

Debug Console output:

=thread-group-added,id="i1"
GNU gdb (Ubuntu 17.1-2ubuntu1) 17.1
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"

Integrated terminal output:

⚠️ warning: GDB: Failed to set controlling terminal: Operation not permitted

Expected behavior

cppdbg should be able to control the inferior normally with gdb 17.1, the same way it does with gdb 16.2:

• stop on breakpoints
• pause on demand
• inspect state
• terminate cleanly

Comparison matrix

Adapter	GDB version	Result
cppdbg	17.1	Fails: inferior starts, VS Code never gains usable control
cppdbg	16.2	Works
webfreak.debug	17.1	Works

Additional observations

Manual MI startup with gdb 17.1 works from the shell:

gdb --interpreter=mi --tty="$(tty)" -q /bin/true

That does not reproduce the freeze by itself, which again points away from a generic TTY problem and toward the interaction between MIEngine and gdb 17.1.

The container is already configured with the usual native-debugging allowances:

• SYS_PTRACE
• seccomp=unconfined
• apparmor=unconfined

So this does not appear to be caused by missing ptrace/container permissions.

Regression suspicion

This looks like a compatibility or regression issue between Microsoft MIEngine and gdb 17.1.

The most relevant facts are:

• cppdbg fails with gdb 17.1
• cppdbg works with gdb 16.2
• another GDB adapter works with gdb 17.1
• plain shell MI startup with gdb 17.1 is possible

Requested guidance

Please clarify:

1. Whether gdb 17.x is officially supported by the current cppdbg / MIEngine implementation.
2. Whether there is a known MI protocol incompatibility or regression with gdb 17.1.
3. Whether the Failed to set controlling terminal warning is expected in remote-container scenarios and, if so, why it results in a non-functional session only for cppdbg.
4. Whether there is a recommended MIEngine setting or launch option for gdb 17.1 in remote Linux containers.

[WardenGnaw]

Is gdb 17.x supported?

Yes. I validated gdb 17.1 on Ubuntu 26.04

Known MI regression in 17.1?

Not that I know of and what I just investigated to check between 16.2 and 17.1

Is the "Failed to set controlling terminal" warning expected?

Yes, and it's a red herring. gdb tries to give the program its own controlling terminal, which isn't permitted in most containers, so it warns and moves on. gdb writes it to the program's terminal, not the channel MIEngine reads, so it doesn't break the session. It showed up in my repro and debugging still worked, so I don't think it's the cause of the freeze.

Recommended setting for containers?

Nothing specific, I was able to debug on containers. I also tried with your container options and didn't hit the issue.

---

Since I couldnt reproduce your issue can you help me get this additional data to help me reproduce your issue?

1. Your setup: Host OS (and WSL2 if Windows), where VS Code runs vs. the container, the container base image, and podman/docker version.
2. A minimal repro: your test-binary source (or a small failing project)
3. An engine log from a failing session. Add this to launch.json, reproduce, and attach the Debug Console output:

"logging": { "engineLogging": true, "trace": true, "traceResponse": true }