X-Spam-Check-By: sourceware.org
Date: Wed, 12 Jul 2006 15:57:33 -0500
From: Brian Ford <Brian DOT Ford AT flightsafety DOT com>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.21s mmap error
In-Reply-To: <20060712202215.GS8759@calimero.vinschen.de>
Message-ID: <Pine.CYG.4.58.0607121536330.3784@PC1163-8460-XP.flightsafety.com>
References: <Pine DOT CYG DOT 4 DOT 58 DOT 0607121030410 DOT 3792 AT PC1163-8460-XP DOT flightsafety DOT com>  <20060712165900 DOT GQ8759 AT calimero DOT vinschen DOT de>  <Pine DOT CYG DOT 4 DOT 58 DOT 0607121318080 DOT 2284 AT PC1163-8460-XP DOT flightsafety DOT com>  <20060712202215 DOT GS8759 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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.

> The message you see is from a call to VirtualProtect, which must not be
> called on reserved pages (which is MEM_RESERVE'd, which is, funny
> enough, the Windows define equivalent to Linux' MAP_NORESERVE).  I fixed
> that in CVS.

Thanks.

> >     addr      = NULL;
> >     virt_size = 0x18000000;
> >     addr = mmap(addr, virt_size, (PROT_READ|PROT_WRITE),
> > 		(MAP_NORESERVE|MAP_PRIVATE|MAP_ANON), fd, 0);
> >     if (addr == MAP_FAILED)
> >     {
> > 	perror("mapping VM scratch space");
> > 	close(fd);
> > 	return -1;
> >     }
> >
> >     *(volatile char *)addr;
>
>       ^^^^^^^^^^^^^^^^^^^^^^^
> This is a bug in your application.

It actually isn't in my application.  I just put it here to test the
validity of the addressed returned.

> You can't rely on being able to access memory mmap'ed with
> MAP_NORESERVE.

Huh?  You mean for read as opposed to write access?  I guess I should have
done this instead:

*(volatile char *)addr = 0;

which is somewhat closer to what my application would be doing, but I
don't understand why a read shouldn't work as well.

They would both fail if there was not enough swap space to allocate the
first page of the map on reference, but that is highly unlikely in this
case.

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

> Thanks for the testcase,

Thank you for your help.  And, sorry for the rant.

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/