Re: [PATCH] wrap-for-bin.sh: facilitate running Git executables under valgrind

From: Jeff King <peff@peff.net>
Date: May 9, 2018, 14:49 UTC
Message-ID: <20180509144958.GB14714@sigill.intra.peff.net>
In-Reply-To: <20180509132858.21936-1-ao2@ao2.it>

On Wed, May 09, 2018 at 03:28:58PM +0200, Antonio Ospite wrote:

Show 20 quoted lines

> Testing locally built git executables under valgrind is not immediate.
> 
> Something like the following does not work:
> 
>   $ valgrind ./bin-wrappers/git
> 
> because the wrapper script forks and execs the command and valgrind does
> not track children processes by default.
> 
> Something like the following may work:
> 
>   $ valgrind --trace-children=yes ./bin-wrappers/git
> 
> However it's counterintuitive and not ideal anyways because valgrind is
> supposed to be called on the actual executable, not on wrapper scripts.
> 
> So, following the idea from commit 6a94088cc ("test: facilitate
> debugging Git executables in tests with gdb", 2015-10-30) provide
> a mechanism in the wrapper script to call valgrind directly on the
> actual executable.

Unfortunately this isn't quite enough to get full valgrind coverage, because Git often execs sub-processes of itself (and for anything that isn't a builtin, all you're checking is the outer "git" process which dispatches to "git-foo").

Show 6 quoted lines

> This mechanism could even be used by the test infrastructure in the
> future, but it is already useful by its own on the command line:
> 
>   $ GIT_TEST_VALGRIND=1 \
>     GIT_VALGRIND_OPTIONS="--leak-check=full" \
>     ./bin-wrappers/git

If you look in t/test-lib.sh, you can see the contortions the test infrastructure goes through to support --valgrind. Basically it creates a parallel bin-wrappers directory where everything gets run under valgrind. ;)

So I dunno. I'm not opposed to this patch in principle if people find it useful. These days _most_ things are builtins, so it would at least cover most of the code you'd want to hit for a debugging session, as long as you're not concerned with full coverage. But I don't think it's the right approach for instrumenting the test suite.

-Peff