public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "Frank Ch. Eigler" <fche@redhat.com>, elfutils-devel@sourceware.org
Subject: Re: patch rfc - valgrind vs. debuginfod
Date: Thu, 17 Jun 2021 12:27:09 +0200	[thread overview]
Message-ID: <18c1ccc2c44a4212a08a9888556781807e8b8e49.camel@klomp.org> (raw)
In-Reply-To: <20210617023413.GP3758@redhat.com>

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

  reply	other threads:[~2021-06-17 10:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17  2:34 Frank Ch. Eigler
2021-06-17 10:27 ` Mark Wielaard [this message]
2021-07-02 16:24   ` Mark Wielaard
2021-07-02 18:06     ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18c1ccc2c44a4212a08a9888556781807e8b8e49.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).