Björn Persson wrote on Thu, Apr 22, 2021 at 04:26:22PM +0200: > It is however a good illustration of how a network problem can destroy > the user experience. Five minutes is a long wait. I'm glad that we now > have this information. This is an old post but I just used debuginfod for the first time (on debian actually (debuginfod 0.183-1, gdb 10.1-1.7) in case things have changed - forgive me and please correct me if anything I've said is significantly better on current version on rawhide), so figured I'd share... - My usecase admitedly wasn't a very nice one (graphical application, info dll says I have 265 linked libraries...), but it felt very slow. Looking at iftop the server was reliably sending me things at 1mbps which isn't great but with the amount of data involved being slow can't be helped, I guess. What makes it really bad is that such applications link extra libraries at runtime, so when I thought it was finally done and it got into the breakpoints I had set, continuing a bit just ran into another wall of downloads, but this also isn't debuginfod's wrongdoings. Most of these libraries are nothing I care about. I understand gdb tries to find debug infos for libraries it encounters when these are loaded into the program's address space, but could it be possible to not download anything at this point and only download debuginfos when they are really used (the first time an address in such libraries appear in a backtrace to get line number / local variables / etc) ? I realize this isn't obvious, but it'd make my usage much more appreciable -- downloading 4 or maybe 5 libraries for the area I'm debugging in that monster instead of the full 265 of them. - None of ^C, ^\, ^Z work, when I grew tired of waiting I had to switch to another terminal and kill the gdb process. It'd be great if e.g. ^C could skip the current download (or future downloads too?) and continue debugging, or enter the (gdb) prompt like it normally does -- iirc it went into that prompt after the download? or batch of downloads I'm not sure, I just remember it took too long. - unsetting DEBUGINFOD_URLS completely disables the debuginfod client, it would have been nice to use the data available in the client cache anyway. Ultimately I set it to localhost so debuginfod would give up immediately on new requests but still use previously downloaded data. Perhaps there could be an "offline mode" of sorts? I also agree with the security concerns given, debuginfos are usually seen as trusted data and I wouldn't be surprised new bugs get found in their parsing which could compromise developers since the server can send whatever it wants to send. I'm not going to be very helpful on that respect though as I don't have any bright idea (distributing just checksums of all debug files in the main package, so when debuginfod downloads something it can compare with the checksum that was installed and verified locally by signed rpm? Didn't reread the whole thread but I think something similar was suggested), but that topic didn't get much discussion and it sounds important to me. All in all I think it's a very valuable tool, but it would be really great if we could minimize the amount of data actually downloaded, and establish some chain of trust. Thanks, -- Dominique _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
