https://bugs.kde.org/show_bug.cgi?id=432215
--- Comment #3 from Aaron Merey <ame...@redhat.com> ---
(In reply to Mark Wielaard from comment #1)
> - It would be nice to not even try if the system doesn't have
> debuginfod-find installed or if DEBUGINFOD_URLS is not set or empty. You can
> check the second with VG_(getenv)("DEBUGINFOD_URLS") and the first by taking
> out ML_(find_executable)("debuginfod-find")) from the new function and
> setting a static debuginfo_find_path variable in slightly earlier startup
> code. You would also set debuginfo_find_path to NULL if DEBUGINFOD_URLS
> wouldn't be set.
Agreed, this will reduce clutter being shown to the user in case
debuginfod-find is installed but debuginfod has been disabled by unsetting
DEBUGINFOD_URLS. Otherwise they could see multiple "Server query failed"
messages unnecessarily.
> - I think you need to drain stderr first in a while loop before doing the
> VG_(waitpid)(pid, NULL, 0); and VG_(read)(out_fds[0], buf, BUF_SIZE);
> because based if the user has set DEBUGINFOD_PROGRESS or DEBUGINFOD_VERBOSE
> stderr can see a lot of output (stdout is always just the filename if
> anything was found).
Good point. It may be easier to simply redirect debuginfod-find's stderr to a
temporary file to avoid any complications with the pipe filling up. The error
message can instead be read from that file if needed.
(In reply to Mark Wielaard from comment #2)
> Also I think all the VG_(umsg) need to be guarded by if (VG_(clo_verbosity)
> > 0) so that there is no extra output when running with valgrind -q.
Ok will add.
--
You are receiving this mail because:
You are watching all bug changes.
