Hi Frank,
On Wed, 2021-06-16 at 22:34 -0400, Frank Ch. Eigler via Elfutils-devel
wrote:
> The following patch appears to make valgrind consistently happy,
> whether distcheck or check runs. It siply arranges to make sure that
> $VALGRIND_CMD is run without debuginfod client being enabled, even as
> the $cmd it runs gets the necessary env var set.
This makes sense, the fedora buildbot worker was upgraded to Fedora 34
over the weekend, which contains valgrind 3.17.0 which has debuginfod
client support and that might interact with the testing...
> I don't completely understand the connection to the weird symptoms
> (32-bit backtraces on 64-bit hosts, missing suppressions?) that we
> noticed earlier.
Yeah, that is a bit of a mystery.
> diff --git a/tests/test-subr.sh b/tests/test-subr.sh
> index 411e5f288acd..2ea6398c0932 100644
> --- a/tests/test-subr.sh
> +++ b/tests/test-subr.sh
> @@ -83,7 +83,7 @@ testrun()
> built_testrun()
> {
>
> LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"\
> - $VALGRIND_CMD "$@"
> + env -u DEBUGINFOD_URLS $VALGRIND_CMD env
> DEBUGINFOD_URLS="$DEBUGINFOD_URLS" "$@"
> }
>
> installed_testrun()
> @@ -104,9 +104,9 @@ installed_testrun()
> if [ "${libdir}" != /usr/lib ] && [ "${libdir}" != /usr/lib64 ]; then
> LD_LIBRARY_PATH="${libdir}:${libdir}/elfutils\
> ${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" \
> - $VALGRIND_CMD $program ${1+"$@"}
> + env -u DEBUGINFOD_URLS $VALGRIND_CMD env
> DEBUGINFOD_URLS="$DEBUGINFOD_URLS" $program ${1+"$@"}
> else
> - $VALGRIND_CMD $program ${1+"$@"}
> + env -u DEBUGINFOD_URLS $VALGRIND_CMD env
> DEBUGINFOD_URLS="$DEBUGINFOD_URLS" $program ${1+"$@"}
> fi
> }
I think there are 3 issues with this implementation of the fix.
First, VALGRIND_CMD could be unset (some testcases that introspect
themselves do that), in which case you are unnecessary running two env
wrappers on the testcase (not a big deal though).
Second this is only one of the places VALGRIND_CMD is used (in run*sh
tests), the other place is in tests/test-wrapper.sh for native tests.
Third valgrind by default only runs on the program it is invoked with.
So in this case it only runs on env, but doesn't run on the actual
program env invokes. For that you'll need to invoke valgrind with --
trace-children=yes.
I think the first can be fixed by simply testing whether VALGRIND_CMD
is set before adding the env wrapping.
The second can be fixed by doing the same env -u env DEBUGNFOD_URLS
wrapping in tests/test-wrapper.sh.
For the third issue we should probably add trace-children=yes to
valgrind_cmd in tests/Makefile.am.
Cheers,
Mark
