From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 4AC743891C18 for ; Thu, 17 Jun 2021 10:27:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4AC743891C18 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 8B4873000D18; Thu, 17 Jun 2021 12:27:09 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 449594019666; Thu, 17 Jun 2021 12:27:09 +0200 (CEST) Message-ID: <18c1ccc2c44a4212a08a9888556781807e8b8e49.camel@klomp.org> Subject: Re: patch rfc - valgrind vs. debuginfod From: Mark Wielaard To: "Frank Ch. Eigler" , elfutils-devel@sourceware.org Date: Thu, 17 Jun 2021 12:27:09 +0200 In-Reply-To: <20210617023413.GP3758@redhat.com> References: <20210617023413.GP3758@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 10:27:13 -0000 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=3D"${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRA= RY_PATH"\ > - $VALGRIND_CMD "$@" > + env -u DEBUGINFOD_URLS $VALGRIND_CMD env DEBUGINFOD_URLS=3D"$DEBUGINFO= D_URLS" "$@" > } > =20 > installed_testrun() > @@ -104,9 +104,9 @@ installed_testrun() > if [ "${libdir}" !=3D /usr/lib ] && [ "${libdir}" !=3D /usr/lib64 ]; t= hen > LD_LIBRARY_PATH=3D"${libdir}:${libdir}/elfutils\ > ${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" \ > - $VALGRIND_CMD $program ${1+"$@"} > + env -u DEBUGINFOD_URLS $VALGRIND_CMD env DEBUGINFOD_URLS=3D"$DEBUGIN= FOD_URLS" $program ${1+"$@"} > else > - $VALGRIND_CMD $program ${1+"$@"} > + env -u DEBUGINFOD_URLS $VALGRIND_CMD env DEBUGINFOD_URLS=3D"$DEBUGIN= FOD_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=3Dyes. 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=3Dyes to valgrind_cmd in tests/Makefile.am. Cheers, Mark