On 12/03/2013 05:08 PM, Eric Blake wrote:
> On 11/28/2013 07:34 AM, Eric Blake wrote:
>
> [back from holidays, so reviving this thread]
>
>>> Michal, since you have the environment to test this, can you rerun:
>>>
>>> ./configure MALLOC_CHECK_=2
>>>
>>> and see if the hang goes away? If so, then I know how to patch gnulib
>>> to ensure that this particular environment variable is always set for
>>> each conftest that tries to tickle a known glibc memory corruption bug.
>
> Michal complained that setting MALLOC_CHECK_ for the entire configure
> slowed things down.
>
>>
>> On IRC, Michal confirmed that this hack patch helped avoid a conftest hang:
>>
>> diff --git i/m4/regex.m4 w/m4/regex.m4
>> index 424ae33..b0eed19 100644
>> --- i/m4/regex.m4
>> +++ w/m4/regex.m4
>> -41,6 +41,15 @@ AC_DEFUN([gl_REGEX],
>> # include <unistd.h>
>> # include <signal.h>
>> #endif
>> +#ifdef __linux__
>> +#include <execinfo.h>
>> +static void __attribute__ ((constructor))
>> +init_backtrace()
>> +{
>> + void *bt[10];
>> + backtrace (bt, 10);
>> +}
>> +#endif
>> ]],
>> [[int result = 0;
>> static struct re_pattern_buffer regex;
>
> He also said this approach worked:
>
> diff --git i/m4/regex.m4 w/m4/regex.m4
> index 424ae33..0089c08 100644
> --- i/m4/regex.m4
> +++ w/m4/regex.m4
> @@ -1,4 +1,4 @@
> -# serial 64
> +# serial 65
>
> # Copyright (C) 1996-2001, 2003-2013 Free Software Foundation, Inc.
> #
> @@ -28,6 +28,7 @@ AC_DEFUN([gl_REGEX],
> # If cross compiling, assume the test would fail and use the included
> # regex.c.
> AC_CHECK_DECLS_ONCE([alarm])
> + AC_CHECK_HEADERS_ONCE([malloc.h])
> AC_CACHE_CHECK([for working re_compile_pattern],
> [gl_cv_func_re_compile_pattern_working],
> [AC_RUN_IFELSE(
> @@ -41,6 +42,9 @@ AC_DEFUN([gl_REGEX],
> # include <unistd.h>
> # include <signal.h>
> #endif
> + #if HAVE_MALLOC_H
> + # include <malloc.h>
> + #endif
> ]],
> [[int result = 0;
> static struct re_pattern_buffer regex;
> @@ -49,11 +53,17 @@ AC_DEFUN([gl_REGEX],
> const char *s;
> struct re_registers regs;
>
> + /* Some builds of glibc go into an infinite loop on this
> + test. Use alarm to force death, and mallopt to avoid
> + malloc recursion in diagnosing the corrupted heap. */
> #if HAVE_DECL_ALARM
> - /* Some builds of glibc go into an infinite loop on this
> test. */
> signal (SIGALRM, SIG_DFL);
> alarm (2);
> #endif
> +#ifdef M_CHECK_ACTION
> + mallopt(M_CHECK_ACTION, 2);
> +#endif
> +
> if (setlocale (LC_ALL, "en_US.UTF-8"))
> {
> {
>
>
> Any preferences on which one I should use in gnulib?
>
>>
>> But then he reported that the check for a working sleep() hung, which
>> makes me wonder if SIGALRM/alarm() semantics are broken on his system.
>
> No idea what was happening here, but it's a separate issue to debug if
> it is still happening.
mallopt seems preferable to me.
thanks,
Pádraig.
