microsoft / microsoft/vscode-cpptools

getRemoteProcessesExtendedRemote() sensitive to gdb warnings

Offen
#13,673 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

debugger help wanted
Vorherrschende Sprache
TypeScript
Sterne
6.2k
Forks
1.7k
Ø Merge
14 Std. 46 Min.
Gemergte PRs (30 T.)
61

Beschreibung

Environment
  • OS and version: Ubuntu 24.04 LTS
  • VS Code:
Version: 1.100.3
Commit: 258e40fedc6cb8edf399a463ce3a9d32e7e1f6f3
Date: 2025-06-02T13:30:54.273Z
Electron: 34.5.1
ElectronBuildId: 11369351
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Linux x64 6.8.0-60-generic snap
  • C/C++ extension: 1.25.3
  • OS and version of remote machine (if applicable):
  • GDB / LLDB version:
$ gdb --version
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 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.
Bug Summary and Steps to Reproduce

Bug Summary:

I am attempting to attach to a gdbserver instance from vscode. My process looks something like this:

  1. Start debugger which kicks off a task that launches a gdbserver instance. I am using bazel run --run_under='gdbserver :14000 so it is not possible for me to have vscode launch gdbserver on a binary directly.
  2. vscode will call gdb -ex "target extended-remote :14000" -ex "info os processes" -batch to get the remote processes
  3. gdb will output a warning like warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. to stderr. This is not an error - the actual gdb invocation for debugging will have the set sysroot / call.
  4. https://github.com/microsoft/vscode-cpptools/blob/3fc041daf68b871bd147ab89b8049111bfedd00c/Extension/src/Debugger/attachToProcess.ts#L199 sees len(stderr) !== 0 and considers the remote process query a failure.

As said above, this warning is okay. I'm not sure what the best way to fix this is.

Debugger Configurations
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "bazel-run-gdbserver",
      "type": "shell",
      "command": "bazel run -c dbg --run_under='gdbserver :14000' ${input:pickBazelTarget}",
      "options": {
        "cwd": "${workspaceFolder}"
      },
      "isBackground": true,
      "problemMatcher": {
        "background": {
          "activeOnStart": true,
          "beginsPattern": "^exec ${PAGER:-/usr/bin/less}.*",
          "endsPattern": "^Listening on port.*",
        },
        "pattern": {
          "regexp": "",
        }
      }
    }
  ],
  "inputs": [
    {
      "id": "pickBazelTarget",
      "type": "command",
      "command": "bazel.pickTarget",
      "args": {
        "query": "kind('cc_binary|cc_test', //...:*)",
        "placeHolder": "Select Bazel target",
      }
    },
  ]
}

launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Bazel Target (Attach)",
      "type": "cppdbg",
      "request": "attach",
      "program": "dummy_binary", // not important, we're not reading symbols from this anyway
      "MIMode": "gdb",
      "useExtendedRemote": true,
      "miDebuggerServerAddress": ":14000",
      "miDebuggerPath": "gdb",
      "setupCommands": [
        {
          "description": "Set local sysroot",
          "text": "set sysroot /",
          "ignoreFailures": true
        },
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "Enable break on all exceptions",
          "text": "catch throw",
          "ignoreFailures": true
        },
        {
          "description": "Set search directory",
          "text": "dir ${workspaceFolder}",
          "ignoreFailures": true
        },
        {
          "description": "bazel-out -> bazel/out",
          "text": "set substitute-path bazel-out bazel/out",
          "ignoreFailures": true
        },
      ],
      "preLaunchTask": "bazel-run-gdbserver",
    }
  ]
}
Debugger Logs
N/A
Other Extensions

BazelBuild.vscode-bazel 0.11.0. Extension is used to help launch the helper task.

Additional Information

No response

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne in Extension/src/Debugger/attachToProcess.ts ungefähr bei Zeile 199 und verfolge den Aufruf von getRemoteProcessesExtendedRemote(), der GDB mit target extended-remote und info os processes ausführt. Führe den Befehl gegen einen gdbserver aus, der die dokumentierte Warnung ausgibt, und überprüfe anschließend, dass die Warnung keinen Fehler mehr verursacht, während echte Fehler bei der Prozessabfrage weiterhin einen Fehler verursachen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
typescript
Bereich
devtools
Issue-Typ
Bug
Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
48/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.