The new debuginfod support in valgrind is rather over eager and will try and fetch a debug image for files which already have debug information. Development builds of the code I work on have about 250 shared libraries which are build with full debugging but are not stripped at all so the debug information is in the main image. Because valgrind has always tried to find a debug image before doing any debug lookups, and because that code not includes trying to search debuginfod for an image, programs now takes several minutes to start while valgrind runs 250 debuginfod-find's each of which makes an HTTP call which gets a negative result. There is currently no negative caching in libdebuginfo (though it is planned) so this isn't even a one time thing.
The negative caching bug is: https://sourceware.org/bugzilla/show_bug.cgi?id=25628
Just to be clear, the libraries I'm talking about here have debug information (that is to say that have populated .debug_xxx sections) but they do not have separate debuginfo images.
Created attachment 138194 [details] patch It looks like these unnecessary queries occur when no .gnu_debuglink section is present in a binary but valgrind nevertheless searches for a separate debuginfo file. I've attached a patch to prevent debuginfod queries in this case.
No that patch won't help. The debugname variable is just the name of the file to look for and is in fact pretty much always set. If .gnu_debuglink was present then crc would be set but modern systems don't use that anyway - they use .note.gnu.build-id instead and that is always set even if debug hasn't been separated out.
Created attachment 138358 [details] Patch to avoid looking for a debuginfo image if the main image has debugging This patch does work for me by avoiding looking for a separate debuginfo image if the main image has debugging. That gets the start time for my case down from 2 minutes to 40 seconds. That's still not the 10 seconds I see when I disable debuginfod completely but it turns out that 30 seconds is the time it takes us to parse the debug information for the system libraries that I didn't previously have debug information for.
(In reply to Tom Hughes from comment #4) > No that patch won't help. > > The debugname variable is just the name of the file to look for and is in > fact pretty much always set. > > If .gnu_debuglink was present then crc would be set but modern systems don't > use that anyway - they use .note.gnu.build-id instead and that is always set > even if debug hasn't been separated out. debugname is set when a .gnu_debuglink or .gnu_debugaltlink section is present and is NULL when there is a build-id but no .gnu_debuglink. It is the latter case in which debuginfod is unnecessary since there is no separate debug file to be found. So I don't see how my patch fails to stop unnecessary debuginfod calls. Regardless your patch is better insofar as it avoids calling find_debug_file altogether for unstripped binaries instead of just skipping find_debug_file_debuginfod.
diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c index b0f062ddc..e424e3e7e 100644 --- a/coregrind/m_debuginfo/readelf.c +++ b/coregrind/m_debuginfo/readelf.c @@ -2879,13 +2879,15 @@ Bool ML_(read_elf_debug_info) ( struct _DebugInfo* di ) /* Look for a build-id */ HChar* buildid = find_buildid(mimg, False, False); - /* Look for a debug image that matches either the build-id or + /* If we don't have a .debug_info section in the main image then + look for a debug image that matches either the build-id or the debuglink-CRC32 in the main image. If the main image doesn't contain either of those then this won't even bother to try looking. This looks in all known places, including the --extra-debuginfo-path if specified and on the --debuginfo-server if specified. */ - if (buildid != NULL || debuglink_escn.img != NULL) { + if (debug_info_escn.img == NULL && + (buildid != NULL || debuglink_escn.img != NULL)) { /* Do have a debuglink section? */ if (debuglink_escn.img != NULL) { UInt crc_offset
The patch has been committed as 93104368952c37268da724231487058ea3eaf1dc.
*** Bug 442061 has been marked as a duplicate of this bug. ***