Description of problem: I just upgraded to F35 and ran a GDB session on an application I'm debugging. The initial startup appeared to just hang with no output for several minutes $ gdb --args ./build/qemu-system-x86_64 -device isa-vga -device isa-cirrus-vga (gdb) run Starting program: /home/berrange/src/virt/qemu/build/qemu-system-x86_64 -device isa-vga -device isa-cirrus-vga ...no output - my app isn't running... ^C Ctrl-C is totally ignored. In another terminal I "killall gdb" and eventually it prints: Cancelling download of separate debug info for /home/berrange/src/virt/qemu/system-supplied DSO at 0x7ffff7fc8000... and then exits I then realized it was still linking to libraries from old F34, so rebuilt my app and tried GDB again: (gdb) run Starting program: /home/berrange/src/virt/qemu/build/qemu-system-x86_64 -device isa-vga -device isa-cirrus-vga Downloading -0.00 MB separate debug info for /lib64/libpixman-1.so.0 [ ]^ It again didn't do more than this for a long while - it didn't seem to print anything in the [...] progress bar space, and as seen it claims to be downlaoding 0 MB. After a few minutes it moved onto the next library. Knowing how many libraries QEMU links to this was going to take hours to download alot of libraries due to my slow network link. I tried Ctrl-C and it did not cancel the downloads I also tried "killall gdb" again and it carried on downloading. The only way I could get GDB to stop this was kill -9. I know you can turn off debuginfo download by unsetting the env var, and did that for now, but it I'd like to see the user experiance improved since downloads are potentially useful - Print size of the library to be downloaded, to let user infer how long it might take - Print progress + download kb/s rate so user can see if it gets stalled - Allow Ctrl-C to interrupt a download at any point - Prompt to ask if user wants to download in the first place Version-Release number of selected component (if applicable): gdb-11.1-5.fc35.x86_64 How reproducible: Somewhat reproducible, especially with slow network link.
Thanks for the bug report (and suggestions). There is an upstream commit which prompts the user whether to use debuginfod. It is likely that this will be backported to Fedora GDB 11.1. There is also a proposed patch - https://sourceware.org/pipermail/gdb-patches/2021-November/183742.html - which adds Ctrl-C support for interrupting debuginfod. When this lands, it'll be backported too. I've passed your other suggestions on to one of the debuginfod developers.
I think that these upstream commits should be backported to Fedora GDB 11.1: 7811fa5995fcb68d30edc0f53d8823c011a12854 - gdb: add set/show commands for managing debuginfod 3ea44f212995117414bf0fee9aaa430f1e59fa20 - gdb.texinfo: Expand documentation for debuginfod 2a8f1f474469bd1a35435deaf5fb0a2ce038071d - Fix unittest.exp failure due to 'set debuginfod' addition 333f35b6315f6ed71db4fb76bfc1ebb7ec347d43 - gdb: rework "set debuginfod" commands These address the matter of asking the user whether to use debuginfod. (Plus fallout after the initial patch was pushed.) I haven't tried to backport them yet; they may need some adjustment. The patch mentioned in Comment 1 about Ctrl-C hasn't made it in yet - it (apparently) still needs approval.
The Ctrl-C patch has landed: b9db26b4c44245c0b0148ef9e711677d4e664f9f - [PR gdb/27026] CTRL-C is ignored when debug info is downloaded ...should be backported for this bug as well.
Great, these sound like promising improvements. Thanks for considering backporting them.
FEDORA-2022-39ffce84e3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-39ffce84e3
FEDORA-2022-39ffce84e3 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-39ffce84e3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-39ffce84e3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e3b891fe11 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e3b891fe11
FEDORA-2022-e3b891fe11 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-e3b891fe11` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e3b891fe11 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-39ffce84e3 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.