Mmap tests on the Hurd

Mmap tests on the Hurd

[Mark Kettenis]

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

   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.

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

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?

Thanks,

Mark

Re: Mmap tests on the Hurd

[Zack Weinberg]

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

Re: Mmap tests on the Hurd

[Mark Kettenis]

   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

Re: Mmap tests on the Hurd

[Zack Weinberg]

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