Re: Mmap tests on the Hurd

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

On Sun, Jan 21, 2001 at 04:45:43PM +0100, Mark Kettenis wrote:
> Hi Zack,
> 
> I'm having some "problems" with the mmap tests on the Hurd:
> 
> 1. Mapping a 2-page region, unmapping its second page and accessing
>    that second page generates a SIGBUS instead of a SIGSEGV.  It looks
>    as if POSIX demands SIGSEGV, but I'm not exactly sure and SIGBUS
>    doesn't sound unreasonable (unmapping the second page can be seen
>    as shrinking the memory object, so in a way we're accessing an
>    undefined part of a memory object here).  Anyway, the Hurd's is
>    pretty much determined by the behaviour of the Mach kernel, so it
>    wouldn't really surprise me if there were more systems out there
>    that show this behaviour (especially if they're Mach bases).

POSIX does demand SIGSEGV.  SIGBUS is only for the case where you
generate a mapping of a _file_ which is larger than the file itself.
Anonymous maps are not file maps, and in no case are address ranges
which have been cleared of mappings to generate SIGBUS.

However, I shan't be picky about it.

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

>    Anyway, would you accept a patch to the tests that would trap
>    SIGBUS as well as SIGSEGV?

Yes.

> 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?

This makes me extremely suspicious, and I will need you to investigate
further.

The whole point of this series of contortions is to ensure that memory
freed by munmap is genuinely freed, and can be reallocated by future
calls to mmap.  This must be the case even if the ranges released by
munmap don't bear any resemblance to the ranges originally allocated
by mmap.

If you don't get two consecutive pages in test_3, then the odds are
that there's a page of memory intervening that hasn't been freed for
some reason.  I don't know what the Mach primitives for this sort of
thing look like.  It's entirely possible that they have problems
similar to Cygwin where a memory map is a solid object which cannot
have holes punched in it.  So there may well be a page left over from
an earlier test.

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.

zw