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

[Mike Hommey]

On Mon, Apr 16, 2012 at 01:59:39PM -0700, Jason Evans wrote:
> 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).

Hoped for 0x7f4d5d7d6000, got 0x7f4d5cfd6000
0x7f4d5dbd6000..0x7f4d5d7d6000..0x7f4d5d3d6000..0x7f4d5cbd6000..0x7f4d5cfd6000

Hoped for 0x7f82e5237000, got 0x7f82e5237000
0x7f82e5637000..0x7f82e5237000..0x7f82e4e37000..0x7f82e4637000..0x7f82e5237000

But anyways, why do you want to do a configure run test when you know
the result you want?

Mike