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