[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hanging conftest

From: Eric Blake
Subject: Re: Hanging conftest
Date: Tue, 03 Dec 2013 20:55:17 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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_ 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]