Re: Mmap tests on the Hurd

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Sun, 21 Jan 2001 10:59:01 -0800
   From: "Zack Weinberg" <zackw@Stanford.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.

Thanks for the explanation.  Looks like I need to do some Mach kernel
hacking :-).

   However, I shan't be picky about it.

Thanks.

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

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

   Yes.

Ok, that one will be coming to gcc-patches in a few days :-).

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

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

Mark