cpptools hardcodes "set debuginfod enabled on" AFTER processing user setupCommands and gdbinit files

[jvillemure]

Type: Bug

GDB hangs during debug launch because debuginfod.ubuntu.com is down #2153433 since yesterday. GDB tries to download debuginfo for every shared library, timing out after ~90s each.

It would be easy to get around this issue by calling the gdb command "set debuginfod enabled off" from a gdbinit file or in "setupCommands", but cpptools doesn't honour those and always end up forcing back "set debuginfod enabled on".

I can't start vscode-server with a modified DEBUGINFOD_URLS="" environment variable; devcontainer add the flag --force-disable-user-env.

The last alternatives are, unsatisfactory, unpleasant workarounds that require either writing system settings file(s) /etc/debuginfod/elfutils.urls (requires admin user) or rebuilding the devcontainer with "remoteEnv": {"DEBUGINFOD_URLS": ""}. These workaround would only be good if they fixed a permanent problem, which is not the case here: as soon as the host "debuginfod.ubuntu.com" is back online the workaround needs to be easily undone.

Expected Behavior: The cppdbg debug adapter should not undo what the developer specifies in gdbinit files or in "setupCommands". In particular, if I "set debuginfod enabled off", then I really mean that my machine or the remote host are not capable of communicating.

Extension version: 1.32.2
VS Code version: Code 1.121.0 (f6cfa2ea2403534de03f069bdf160d06451ed282, 2026-05-19T11:51:53+02:00)
OS version: Windows_NT x64 10.0.26200
Modes:
Remote OS version: Linux x64 6.6.114.1-microsoft-standard-WSL2

System Info

Item	Value
CPUs	13th Gen Intel(R) Core(TM) i7-13850HX (28 x 2304)
GPU Status	2d_canvas: enabled GPU0: VENDOR= 0x10de, DEVICE=0x27bb [NVIDIA RTX 3500 Ada Generation Laptop GPU], DRIVER_VENDOR=NVIDIA, DRIVER_VERSION=32.0.15.8195 ACTIVE GPU1: VENDOR= 0x8086, DEVICE=0xa788 [Intel(R) UHD Graphics], DRIVER_VERSION=32.0.101.7084 GPU2: VENDOR= 0x1414, DEVICE=0x008c [Microsoft Basic Render Driver], DRIVER_VERSION=10.0.26100.8328 Machine model name: Machine model version: direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off trees_in_viz: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	31.69GB (14.91GB free)
Process Argv	--crash-reporter-id 0ee9c5df-6520-4de7-8875-9c23c4ea84c3
Screen Reader	no
VM	0%

Item	Value
Remote	Dev Container: Atlas Dev
OS	Linux x64 6.6.114.1-microsoft-standard-WSL2
CPUs	13th Gen Intel(R) Core(TM) i7-13850HX (28 x 0)
Memory (System)	15.46GB (11.99GB free)
VM	0%

A/B Experiments

vsliv368cf:30146710
pythonvspyt551:31249599
binariesv615:30325510
nativeloc1:31344060
dwcopilot:31170013
dwoutputs:31242946
copilot_t_ci:31333650
e5gg6876:31282496
pythonrdcb7:31342333
6518g693:31463988
aj953862:31281341
6abeh943:31336334
envsdeactivate2:31505458
cloudbuttont:31379625
3efgi100_wstrepl:31403338
839jf696:31457053
ec5jj548:31422691
cp_cls_t_966_ss:31454198
inlinechat_v2_hd992725:31505030
4je02754:31466945
c3h7c220:31478652
ge8j1254_inline_auto_hint_haiku:31490510
38bie571_auto:31478677
cp_cls_t_1081:31454832
conptydll_true:31498968
ia-use-proxy-models-svc:31452481
e9c30283:31461165
test_treatment2:31471001
46204921:31447328
idci7584:31464702
e3e4d672:31494082
ei9d7968:31496641
nes-extended-on:31455476
chat:31457767
8hig5102:31480529
89g7j272:31518289
7e187181:31503455
i2gc6536:31499202
52612955:31516516
ghj88844:31499326
h08i8180_copy:31475368
ddid_t:31478206
hmra_i5g22:31518061
getcmakediagnosticson:31489824
7df3h592:31512476
pro_large_t:31499376
cp_cls_t_1082:31516087
logging_enabled_new:31498466
j0d79568:31499440
jb_cp_cls_c_632:31517842
b1ei0813:31506238
748c7209:31512887
cg448276_tst_on:31514358
32d76977:31512328
ha629193:31508444
539gd155_c:31506875
a1ije391_t:31515488
g4a0e106:31517209
prpt_ctrl:31518467
61138546:31518536

[sean-mcmanus]

@jvillemure Is this fixed by microsoft/vscode-cpptools#14471 ?

[jvillemure]

@jvillemure Is this fixed by #14471 ?

microsoft/vscode-cpptools#14471 is related, and fixes the hanging that occurs when http://debuginfod.ubuntu.com is down or not responding. But the current issue goes somewhat further: the problem is that the cpp debug adapter force overwrite the debuginfod enabled on setting even if the launch configuration provided a "setupCommand": { "text": "debuginfod enabled off"}. The expected behaviour would be to honour the launch configuration: keep the debuginfod disabled.

The solution in microsoft/vscode-cpptools#14471 resolve the issue by eventually calling the gdb command set debuginfod enabled off by exposing a new launch configuration setting:

"debuginfod": {
    enabled: false, // to disable downloading
    // timeout: 3 or use a small timeout (gdb 15 doesn't have this setting)
}

In principle, it should also be possible to achieve exactly the same behaviour by using an appropriate setting in the debug config's "setupCommands":

{
    "text": "set debuginfod enabled off"
}

And this should behave similarly to placing the command set debuginfod enabled off within a gdb initialization file; say the user specific one ~/.config/gdb/gdbinit. Using the user specific gdb init file is the best strategy to temporarily fix the hanging when the debuginfod remote is not reachable because it necessitates a single change in a single file, it applies to any gdb debug session, the file is easily modified because it is owned by the user, and changes can be easily undone once the remote debuginfod server comes back online.

Contrast this to the solution in microsoft/vscode-cpptools#14471 which propose a per cppdbg launch config: the change is not localized, all the cppdbg launch configurations that a user wants to launch need to add a temporary "debuginfod" setting; the affected launch config files are often tracked in git so the user needs to do gymnastics when committing and pulling, the change only affect cppdbg so the settings would also needs to be within the user's gdbinit file to use gdb from cli, undoing those changes requires more attention.

[sean-mcmanus]

@jvillemure I believe this requires an MIEngine fix. Can you re-file it there? https://github.com/microsoft/MIEngine/issues Or do you want me to? I don't have permissions to transfer it directly. h

[jvillemure]

I did some experimentation with cppdbg debug adapter to better understand the sequence of gdb commands it executes at startup. I used a minimal cppdbg launch configuration with engineLogging enabled. I used both a setupCommands and a gdbinit file to setup set debuginfod enabled off. My gdbinit file has echo commands at the beginning and end to highlight when it is sourced. The logs shows that gdbinit is sourced first, then -gdb-set mi-async on gets called, then setupCommands gets invoked, and then followed by other gdb commands which includes the offending set debuginfod enabled on.

After some thought, I kind of guessed that debuginfod is probably hardcoded to enabled on because the default setting in gdb would be enabled ask which requires waiting on for user interaction; this might itself cause hanging if the debug adapter can not notify the programmer for input (and this would also become annoying for the programmer to (almost) always type "yes" -- unless the debuginfod happens to be down).

Would it be possible that the startup only change debuginfod enable setting when it is set to ask and leave it as it is otherwise?

[gregg-miskelly]

There is already a completed MI Engine PR to add a setting for this: PR, Issue.
The work around until we get this merged: run GDB from an environment with DEBUGINFOD_URLS set to an empty string

[gregg-miskelly]

Resolving as duplicate of #1562

[sean-mcmanus]

@jvillemure @gregg-miskelly Is this really a duplicate?

[gregg-miskelly]

@sean-mcmanus Yes. Andrew is using microsoft/vscode-cpptools#14458 as the root issue since that will be more visible. We are talking with the team who enabled debuginfod by default to see if we want to switch the default value.