This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Hanging conftest
- From: PÃdraig Brady <P at draigBrady dot com>
- To: Eric Blake <eblake at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Michal Privoznik <mprivozn at redhat dot com>, libc-alpha at sourceware dot org, bug-gnulib at gnu dot org
- Date: Wed, 04 Dec 2013 03:38:33 +0000
- Subject: Re: Hanging conftest
- Authentication-results: sourceware.org; auth=none
- References: <529624A0 dot 2020106 at redhat dot com> <52962B78 dot 20003 at redhat dot com> <20131128050020 dot GE20495 at spoyarek dot pnq dot redhat dot com> <52974B01 dot 9000704 at redhat dot com> <5297548F dot 7020902 at redhat dot com> <529E0FF4 dot 8000004 at redhat dot com>
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.