This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.21s mmap error

On Jul 12 15:57, Brian Ford wrote:
> On Wed, 12 Jul 2006, Corinna Vinschen wrote:
> > The problem results from introducing MAP_NORESERVE in 1.5.19.  That's
> > the reason the same code works on 1.5.18.  Your code simply defines
> > MAP_NORESERVE to 0 under 1.5.18.
> While that is true, I compiled the STC with MAP_NORESERVE defined under
> the 1.5.21s headers, and then ran the binary without recompiling it under
> 1.5.[18-20].  So, you must have ignored the MAP_NORESERVE value in the
> older releases since it was passed to mmap in my test.

Right, only the correctness of the POSIX flags is checked at the start
of mmap.  Any non-standard flags are usually ignored.

> > This might succeed on Linux, but it's not guaranteed.  It certainly
> > doesn't work this way on Cygwin.  Call something like `mprotect (addr,
> > virt_size, PROT_READ|PROT_WRITE)' before accessing the mmap'ed memory.
> Why?  I already told mmap it should have these attributes.
> There is a bug in one of our understandings of MAP_NORESERVE symantics.
> My understanding of MAP_NORESERVE is from the Solaris man page:
>      The MAP_NORESERVE option specifies that  no  swap  space  be
>      reserved for a mapping. Without this flag, the creation of a
>      writable MAP_PRIVATE mapping reserves swap  space  equal  to
>      the  size  of the mapping; when the mapping is written into,
>      the reserved space  is employed to hold  private  copies  of
>      the  data.  A  write  into  a MAP_NORESERVE mapping produces
>      results which depend on the  current  availability  of  swap
>      space  in  the  system.   If  space  is available, the write
>      succeeds and a  private copy of the written page is created;
>      if  space  is not available, the write fails and a SIGBUS or
>      SIGSEGV  signal  is  delivered  to  the   writing   process.
>      MAP_NORESERVE  mappings are inherited across  fork(); at the
>      time of the fork(), swap space is reserved in the child  for
>      all  private  pages  that  currently  exist  in  the parent;
>      thereafter the child's mapping behaves as described above.
> So, the only difference with MAP_NORESERVE is that swap space is not
> reserved up front, but on reference (read is unclear from this
> description, but write is definately clear).  If on reference we run out
> of swap, SIGBUS is generated.
> What am I missing?

I just read the Linux man page (again), and I seem to have missed some
important bits.  The above semantics are not implemented this way in
Cygwin.  A private anonymous mmap is actually just an area allocated
with VirtualAlloc.  A MAP_NORESERVE area is not commited (MEM_COMMIT)
but just reserved (MEM_RESERVE).  What's missing is the automatic
commiting when a page fault on one of these pages occurs.  I added an
(hopefully) appropriate patch, which commits a page within a
MAP_NORESERVE area when memory in this page is accessed by the
application.  If commiting the memory fails, SIGBUS is generated.
Please test CVS HEAD or the next developer snapshot from

Note however, that MAP_NORESERVE is only implemented for private
anonymous mappings.  Shared anonymous maps seem to be possible (and
would probably make sense to minimze the swap space footprint), but are
somewhat tricky since it's not quite clear what happens to memory which
is commited in one process and then accessed in another.  This would
require some extensive testing which I'm not willing to do yet.

File-backed mappings are always ignoring the MAP_NORESERVE flag and are
using committed memory, since uncommitted file maps are not supported on


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]