Hello Gnulib,
The ‘test-lock’ test as shipped with gettext-0.19.8.1 fails to complete
(or hangs?) on machines with 32+ cores, as reported here:
https://bugs.gnu.org/26441
Does that ring a bell?
Mathieu Othacehe found that this is fixed by gettext commit
1afbcb06fded2a427b761dd1615b1e48e1e853c
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: fr
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
On 12 April 2017 at 13:47, Reuben Thomas wrote:
>
>
> 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.
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 invo
Hi Reuben,
> 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.
On 12 April 2017 at 15:23, Bruno Haible wrote:
> Hi Reuben,
>
> > 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
>
Hi Ludo,
> The ‘test-lock’ test as shipped with gettext-0.19.8.1 fails to complete
> (or hangs?) on machines with 32+ cores, as reported here:
>
> https://bugs.gnu.org/26441
>
> Does that ring a bell?
Yes, this is the bug that was investigated in December 2016 [1] and
subsequently fixed [2].
Hi Bruno,
Bruno Haible skribis:
>> The ‘test-lock’ test as shipped with gettext-0.19.8.1 fails to complete
>> (or hangs?) on machines with 32+ cores, as reported here:
>>
>> https://bugs.gnu.org/26441
>>
>> Does that ring a bell?
>
> Yes, this is the bug that was investigated in December 201
