"Phillip Wood via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>
>
> 131b94a10a ("test-lib.sh: Use GLIBC_TUNABLES instead of MALLOC_CHECK_
> on glibc >= 2.34", 2022-03-04) introduced a check for the version of
> glibc that is in use. This check is performed as part of
> setup_malloc_check() which is called at least once for each test. As
> the test involves forking `getconf` and `expr` cache the result and
> use that within setup_malloc_check() to avoid forking these extra
> processes for each test.
>
> Signed-off-by: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>
> ---
> tests: cache glibc version check
>
> A recent discussion on the list[1] reminded me that this patch was
> waiting to be sent.
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1311%2Fphillipwood%2Fwip%2Ftest-cache-glibc-tunables-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1311/phillipwood/wip/test-cache-glibc-tunables-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1311
>
> t/test-lib.sh | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 7726d1da88a..ad81c78fce7 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -557,14 +557,19 @@ then
> : nothing
> }
> else
> + _USE_GLIBC_TUNABLES=
> + if _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&
> + _GLIBC_VERSION=${_GLIBC_VERSION#"glibc "} &&
> + expr 2.34 \<= "$_GLIBC_VERSION" >/dev/null
> + then
> + _USE_GLIBC_TUNABLES=YesPlease
> + fi
> setup_malloc_check () {
> local g
> local t
> MALLOC_CHECK_=3 MALLOC_PERTURB_=165
> export MALLOC_CHECK_ MALLOC_PERTURB_
> - if _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&
> - _GLIBC_VERSION=${_GLIBC_VERSION#"glibc "} &&
> - expr 2.34 \<= "$_GLIBC_VERSION" >/dev/null
> + if test -n "$_USE_GLIBC_TUNABLES"
> then
> g=
> LD_PRELOAD="libc_malloc_debug.so.0"
Between USE_LIBC_MALLOC_DEBUG, which is the name Peff originally
gave this intermediate variable, and the one you use here, I am
undecided. If the only thing the GLIBC_TUNABLES mechanism can do
were to tweak the malloc checking, then both names are good, but
that is not the case. We are only seeing if we are going to use the
malloc check feature given by glibc here, so the original name feels
more to the point, and use of GLIBC_TUNABLE mechanism to trigger
that malloc check feature is a mere implementation detail.
But that is minor. Let's queue the patch to help me not to forget
about it, and we'll amend it if necessary, as we'd probably need a
helped-by or signed-off-by from Peff anyway before this hits 'next'.
Thanks.
