[7ca0fdf] Disable munmap() if it causes VM map holes

[Jason Evans]

On Apr 16, 2012, at 1:19 PM, Mike Hommey wrote:
> On Mon, Apr 16, 2012 at 12:07:58PM -0700, Jason Evans wrote:
>> On Apr 16, 2012, at 8:08 AM, Mike Hommey wrote:
>>> I noticed something "interesting" with the test for VM map holes: If
>>> I compile it manually, it fails:
>>> 
>>> Hoped for 0x7f835133d000, got 0x7f8350b3d000
>>> 0x7f835173d000..0x7f835133d000..0x7f8350f3d000..0x7f835073d000..0x7f8350b3d000
>>> 
>>> Apparently, this happens when *not* linking libm to the testcase. It
>>> also does happen when linking libm and some other library (tried
>>> pthread and stdc++).
>> 
>> What OS is this on?  The test should fail on Linux, but not OS X or
>> FreeBSD.  Linux has a VM map management quirk (on at least x86) that
>> causes accumulation of VM map holes under normal operation.
> 
> Linux x64. Kernel 3.2.
> 
> So, you are saying that this error is the "expected" behaviour, except I
> actually don't get it under "normal" conditions (those of configure.ac)

Hmm, maybe those extra libraries are creating another hole that's preventing the initial series of mmap calls from getting contiguous memory.  Can you move the two fprintf calls ("Hoped for …" and the next one) out of the conditional block and pull the resulting output from config.log?  That'll help me understand what's happening so that I can refine the test.  (I can't reproduce the problem on the Linux machines I'm using).

Thanks,
Jason