Re: Mmap tests on the Hurd

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Sun, Jan 21, 2001 at 11:46:44PM +0100, Mark Kettenis wrote:
>    >    As a sidenote, the fact that the autoconf tests die with a fatal
>    >    signal is a bit annoying, since the Hurd's default behaviour is to
>    >    suspend the program instead of dumping core (such that you can
>    >    attach the debugger to it) which means that the whole configuration
>    >    process is suspended.
> 
>    Is there a way to override this for just the test process?  We don't
>    need a core dump, just a forcible process exit.
> 
> In principle there is.  From looking at the code setting the
> environment variable CRASHSERVER to /dev/null should work, but I
> haven't verified this.  But if SIGBUS is trapped in the same way as
> SIGSEGV, there is no real need to infect the test program with
> Hurd-specific mumbo-jumbo.

I think it might be wise to infect the entire configure script with
this particular mumbo jumbo, as you put it.  What if some other test
process gets a fatal signal?  The naive user will see configure hang
with no explanation.  [This should really be dealt with by the
autoconf maintainers, but gcc's got plenty of local hacks already...]

>    > 2. The Hurd is "so perverse as to leave unmapped space between
>    >    consecutive calls to mmap" :-).  I'm not exactly sure why.  It can
>    >    probably be blamed on Mach, or there might be a "bug" in the Hurd's
>    >    mmap implementation here.  Do you really need this behaviour?
...
>    Could you please instrument anonmap() in the test so it prints the
>    address and size of each allocation, then run the test again, and
>    examine the results carefully?  If addresses allocated in the first
>    two tests are not being recycled, that's a serious problem.
> 
> OK, thanks for the explanation.  I did some further investigation, and
> things turn out to be ... interesting.  The addresses are properly
> recycled.  However, it turns out that when the test program enters
> main(), its VM space has some similarities with swiss cheese :-).  The
> exact layout probably depends on the libc version, but in my
> particular case there are some one-page holes.

Ah, that makes sense.  I wonder if that indicates memory leaks in
libc, or just random one-page internal allocations that are still in
use.  I've seen the same effect on Linux by opening and closing stdio
FILEs (the buffer is mmaped for some odd reason).

> It's these one-page holes that are returned by anonmap() in
> test_3(), hence the nonconsecutive pages.  When I doubled the unit
> of allocation in the test-program, the tests succeeded.  But, at
> least in principle, this is just as fragile; there is no reason why
> there cannot be a couple of two-page holes.
>
> I don't see an easy way out.  In theory test_3() is fragile, but on
> most common systems out there it seems to work fine.  Until I come up
> with a solution, I think it's best to add a comment about the Hurd in
> the test and pretend that the Hurd doesn't support anonymous virtual
> memory.

At one point I had a loop in test_3 that allocated page after page
until it got two consecutive ones or hit some threshold at which it
gave up.  How many holes were there?

zw