This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hanging conftest


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.

Unfortunately I'm seeing cores with this.

#0  0x000000375ce35215 in raise	() from /lib64/libc.so.6
#1  0x000000375ce36b2b in abort	() from /lib64/libc.so.6
#2  0x000000375ce78550 in malloc_printerr () from /lib64/libc.so.6
#3  0x000000375ce79fc0 in _int_malloc () from /lib64/libc.so.6
#4  0x000000375ce7a836 in malloc_check () from /lib64/libc.so.6
#5  0x000000375ce7d4bf in calloc () from /lib64/libc.so.6
#6  0x000000375cebb6b4 in re_acquire_state_context () from /lib64/libc.so.6
#7  0x000000375cec1e6a in re_search_internal ()	from /lib64/libc.so.6
#8  0x000000375cec64ac in re_search_stub () from /lib64/libc.so.6
#9  0x000000375cec6eb8 in re_search () from /lib64/libc.so.6
#10 0x000000000040081c in main () at t.c:84

Ah so mallopt(M_CHECK_ACTION, 2) is documented to abort() on error.
I suppose we need to suppress core dumps now with the gnulib
]GL_NOCRASH[ ... nocrash_init() guard?
Actually no, that doesn't catch SIGABRT.
So I suppose you need an explicitly exit(1) in a SIGABRT
signal handler in this test?

thanks,
PÃdraig.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]