Problem with valgrind-tests: relies on bash not causing error

[Reuben Thomas]

The test for whether to use valgrind runs:

/bin/bash -c 'exit 0'

This looks pretty harmless; unfortunately, bash itself causes problems:

$ valgrind -q --error-exitcode=1 --leak-check=full /bin/bash -c 'exit 0'
==32197== Invalid free() / delete / delete[] / realloc()
==32197== at 0x4C2ED5B: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32197== by 0x45E1D0: ??? (in /bin/bash)
==32197== by 0x45E37F: run_unwind_frame (in /bin/bash)
==32197== by 0x47B664: parse_and_execute (in /bin/bash)
==32197== by 0x4209D6: ??? (in /bin/bash)
==32197== by 0x41F893: main (in /bin/bash)
==32197== Address 0x423b828 is in the brk data segment 0x4228000-0x423bfff
==32197==

Here I was using the provided Ubuntu 16.04 build of bash:

$ bash --version
GNU bash, version 4.3.46(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.

Maybe use some other known-available utility that doesn't play weird tricks
with memory? /bin/ls works for me!

[Reuben Thomas]

​Having applied the workaround of using "ls" in the configure test, my
tests still don't run because the LOG_COMPILER trick suggested in the
gnulib manual doesn't take account of libtool wrappers. Net result:
valgrind is being called on bash (as it runs the test binary's wrapper
script).

This is a separate issue, though: the real problem here is that a way is
needed to run libtool wrappers with libtool, so that they are executed as:

libtool --mode=execute valgrind $LIBTOOL_WRAPPER_SCRIPT

The problem is that it's not obvious where the responsibility should lie. I
don't expect automake to go examining all my test scripts to see if they
look like libtool wrappers; on the other hand, I'm not sure what libtool
can do, since by the time its wrapper has been run under valgrind, it's too
late.

For now I'll simply write manual scripts to call my tests and pass the
value of $VALGRIND in, but I would appreciate suggestions here. I find
valgrind invaluable, so making it easy to run such tests (so that it's just
a question of adding the "valgrind-tests" module to one's project and
making a couple of Makefile.am settings) would be great.

I guess one further option is to fix the bug in bash, and then call
valgrind with --trace-children=yes. Maybe that would be cleanest and
simplest (albeit we'll need a workaround until fixed bash is widely
available).

[Reuben Thomas]

Post by Reuben Thomas
I guess one further option is to fix the bug in bash, and then call
valgrind with --trace-children=yes. Maybe that would be cleanest and
simplest (albeit we'll need a workaround until fixed bash is widely
available).

​I tested bash 4.4, and got exactly the same problem.

I see there's a Debian bug open for this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517

I get the bug if I do a build of bash from GNU sources (i.e. it doesn't
seem to be a Debian patch causing the problem). I can't find anything about
this in the bug-bash archives (there is discussion of other valgrind
diagnostics, but not this one), so I've reported a bug there.

[Bruno Haible]

Hi Reuben,

Post by Reuben Thomas
This is a separate issue, though: the real problem here is that a way is
needed to run libtool wrappers with libtool

In GNU gettext, I never succeeded in making valgrind work with the libtool
wrappers; instead I noted
# You should build with --disable-shared when using valgrind.

See [1], lines 170..199.

Bruno

[1] http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/tests/Makefile.am

[Reuben Thomas]

Post by Bruno Haible
Hi Reuben,

Post by Reuben Thomas
This is a separate issue, though: the real problem here is that a way is
needed to run libtool wrappers with libtool

In GNU gettext, I never succeeded in making valgrind work with the libtool
wrappers; instead I noted
# You should build with --disable-shared when using valgrind.
See [1], lines 170..199.
Bruno
[1] http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;
f=gettext-tools/tests/Makefile.am

This is not feasible for ​Enchant, which is based around dynamically-loaded
libraries.

​However, I just used a one line shell script, called run-test:

#!/bin/sh
libtool --mode=execute $VALGRIND "$@"
​
​and then in Makefile.am:

​LOG_COMPILER = $(srcdir)/run-test

It is working for me, and I'm happily fixing the bugs found by Valgrind.

[Bruno Haible]

Hi Reuben,

Post by Reuben Thomas
/bin/bash -c 'exit 0'

I'd suggest that you change m4/valgrind-tests.m4 to use the AC_CACHE_CHECK
macro instead of "lone" AC_MSG_CHECKING and AC_MSG_RESULT invocations.
Then you have an cache variable that you set as an environment variable
in order to override the result of this test, e.g.
$ env gl_cv_use_valgrind=yes ./configure

Remember, nowadays that the autoconf cache is disabled by default, the
major benefit of AC_CACHE_CHECK is that it provides the user a way to
selectively override configure test results.

Bruno

[Marc Nieper-Wißkirchen]

Hi Bruno,

Hi Reuben,

/The test for whether to use valgrind runs:/
//
//bin/bash -c 'exit 0'/
//
/This looks pretty harmless; unfortunately, bash itself causes problems:/

I'd suggest that you change m4/valgrind-tests.m4 to use the AC_CACHE_CHECK
macro instead of "lone" AC_MSG_CHECKING and AC_MSG_RESULT invocations.
Then you have an cache variable that you set as an environment variable
in order to override the result of this test, e.g.
$ env gl_cv_use_valgrind=yes ./configure

Remember, nowadays that the autoconf cache is disabled by default, the
major benefit of AC_CACHE_CHECK is that it provides the user a way to
selectively override configure test results.

Bruno

Today I have run into the same problem (namely that valgrind and bash
are not going along very well).

While your proposed solution would work for anyone who is aware of this
problem, it won't work for an unaware user who would simply run
./configure, wondering why valgrind isn't detected. As it seems rather
involved to resolve the incompatibility between bash and valgrind, I
would like to ask to have gnulib's valgrind-tests changed upstream. As
this change amounts simply in replacing $(SHELL) by any other well-known
utility, the changes to be done are trivial.

Having an updated version upstream makes it much easier for everyone to
pick up the necessary changes to make valgrind-tests work.

Marc

[Bernhard Voelker]

While your proposed solution would work for anyone who is aware of this problem, it won't work for an unaware user who would simply run ./configure, wondering why valgrind isn't detected. As it seems
rather involved to resolve the incompatibility between bash and valgrind, I would like to ask to have gnulib's valgrind-tests changed upstream. As this change amounts simply in replacing $(SHELL) by
any other well-known utility, the changes to be done are trivial.

/bin/true seems fine, doesn't it?

Have a nice day,
Berny

[Reuben Thomas]

Post by Reuben Thomas
/bin/bash -c 'exit 0'
$ valgrind -q --error-exitcode=1 --leak-check=full /bin/bash -c 'exit 0'
==32197== Invalid free() / delete / delete[] / realloc()
==32197== at 0x4C2ED5B: free (in /usr/lib/valgrind/vgpreload_
memcheck-amd64-linux.so)
==32197== by 0x45E1D0: ??? (in /bin/bash)
==32197== by 0x45E37F: run_unwind_frame (in /bin/bash)
==32197== by 0x47B664: parse_and_execute (in /bin/bash)
==32197== by 0x4209D6: ??? (in /bin/bash)
==32197== by 0x41F893: main (in /bin/bash)
==32197== Address 0x423b828 is in the brk data segment 0x4228000-0x423bfff
==32197==
$ bash --version
GNU bash, version 4.3.46(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
Maybe use some other known-available utility that doesn't play weird
tricks with memory? /bin/ls works for me!

​Attached, a patch to fix this. (I believe this change is still needed.)

[Paul Eggert]

Thanks, I installed the attached somewhat-more-fancier patch; does it work for you?

[Reuben Thomas]

Post by Paul Eggert
Thanks, I installed the attached somewhat-more-fancier patch; does it work for you?

​That works fine; thanks very much.