Re: Hanging conftest

[Eric Blake]

On 12/03/2013 08:31 PM, Siddhesh Poyarekar wrote:
> On Tue, Dec 03, 2013 at 10:08:04AM -0700, Eric Blake wrote:
>> Michal complained that setting MALLOC_CHECK_ for the entire configure
>> slowed things down.
> 
> That's funny because...
> 
>>  #endif
>> +#ifdef M_CHECK_ACTION
>> +            mallopt(M_CHECK_ACTION, 2);
>> +#endif
>> +
> 
> ... this should have the same effect as MALLOC_CHECK_, i.e. it should
> enable the extra checking and slow things down in the same manner as
> MALLOC_CHECK_.

MALLOC_CHECK_ in the environment at the start of ./configure affects
hundreds or even thousands of processes.  mallopt() within a single
conftest affects only the one process.  I found it slightly easier to
use mallopt() within the conftest code than to figure out how to ensure
I was injecting MALLOC_CHECK_ into the environment of the m4 code that
runs the conftest program without also leaking into the environment of
the rest of the configure script.

>  However, it looks like we don't do __malloc_check_init
> for M_CHECK_ACTION, which is what initializes the additional checks.
> Does anyone know if it is intentional?  It looks like a bug to me.

That's more a matter for glibc to decide; for now, all I was worried
about was patching gnulib in a manner that would prevent configure from
hanging (besides, the hang is a real problem in glibc versions in use in
the wild, while any change to mallopt(), __malloc_check_init,
MALLOC_CHECK_, or otherwise will take several months if not years to
percolate into being commonly available).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature