On Wed, May 09, 2018 at 03:28:58PM +0200, Antonio Ospite wrote:
> 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").
> 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
