`cppdbg` / MIEngine loses debugger control with `gdb 17.1` in Linux dev container, while `gdb 16.2` works
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- csharp
- Área
- devtools, operating-systems
Línea de trabajo
Empieza reproduciendo la matriz de comparación del issue: cppdbg con GDB 17.1 y 16.2, y después el comando manual de inicio de MI. Lee el comportamiento de MIEngine en torno al lanzamiento, el control y la interacción con el terminal reportados; se considera completado cuando se haya identificado la causa de compatibilidad y se hayan restablecido los breakpoints, la pausa, la inspección y la terminación limpia con GDB 17.1.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
gdbprocess must be killed manually.
The same setup works when either of these is true:
cppdbgusesgdb 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)
gdbfailing withcppdbg:GNU gdb (Ubuntu 17.1-2ubuntu1) 17.1gdbworking withcppdbg: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-x64ms-vscode.cpp-devtools 0.5.13ms-vscode.cmake-tools 1.23.52webfreak.debug 0.27.0vadimcn.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/ptsis mounted and usablettyreturns a valid pseudo-terminalkernel.yama.ptrace_scope = 1NoNewPrivs: 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
gdbis 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_PTRACEseccomp=unconfinedapparmor=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:
cppdbgfails withgdb 17.1cppdbgworks withgdb 16.2- another GDB adapter works with
gdb 17.1 - plain shell MI startup with
gdb 17.1is possible
Requested guidance
Please clarify:
- Whether
gdb 17.xis officially supported by the currentcppdbg/ MIEngine implementation. - Whether there is a known MI protocol incompatibility or regression with
gdb 17.1. - Whether the
Failed to set controlling terminalwarning is expected in remote-container scenarios and, if so, why it results in a non-functional session only forcppdbg. - Whether there is a recommended MIEngine setting or launch option for
gdb 17.1in remote Linux containers.
- Lenguaje dominante
- C#
- Estrellas
- 861
- Forks
- 233
- Merge medio
- 10 h 31 min
- PR fusionados (30 d)
- 2
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/MIEngine
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
-
When debugging multiple inferiors with gdb, if one inferior exits the full debug session stopsAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
MiEngine fails to start GDB 17Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
Todos los issues de microsoft/MIEngine
Issues similares
-
A numeric literal is parsed in the host's culture, so 1.5 is 15 in a made EXE on a comma-decimal OSAbiertobug interpreter silently-wrong small
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
reactiveui/ReactiveUI.Binding.SourceGenerators#176 ·
Los mantenedores suelen responder en 1 día
-
c:docs p:high size:S t:docs
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
lugassawan/swe-workbench#799 ·
Los mantenedores suelen responder en 1 día
-
.NET Docs Next Major
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
getsentry/sentry-dotnet#5709 · 1 comentario ·
Los mantenedores suelen responder en 2 días