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
