1.7.0 CVS mmap failure
Wed Jan 10 16:12:00 GMT 2007
On Jan 10 09:37, Brian Ford wrote:
> On Fri, 5 Jan 2007, Corinna Vinschen wrote:
> > Actually this shows a problem in the mmap implementation with respect to
> > MEM_TOP_DOWN. I think, what mmap should actually do is to create a
> > lightweight MAP_RESERVE anonymous mapping of the whole requested mapping
> > size, then close it again and then reopen it with the address it got
> > in this first try. This would probably ensure that the subsequent two
> > mapping will work.
> Why MAP_RESERVE if the requested mapping is NO_RESERVE? This is just
> about whether you have swap (paging file) space initially committed or
> not, right?
MAP_RESERVE is Windows speak, NO_RESERVE is POSIX speak. Using the same
term doesn't always mean the same. The MSDN description of VirtualAlloc
is very helpful here.
> > This should work (knock on wood) on all systems now. My testcases still
> > work on my 512 MB machine, so I'd appreciate if you could give the latest
> > snapshot a try on /3GB enabled machines.
> Yes, this fixes my STC and the application from which it was derived.
Glad to hear.
> > The 2nd problem: POSIX allows file mappings to exceed the file size,
> > Windows doesn't. If the code tries to map a bigger size, the file on
> > disk is automatically extended to the size of the map. The current
> > solution restricts the mapping always to the end of the file, so that it
> > isn't changed by the mapping size. If the offset is beyond EOF, mmap
> > fails with ENXIO. My patch uses the AT_EXTENDABLE_FILE flag in a call
> > to ZwMapViewOfSection which allows POSIX semantics. But as you might
> > guess, this has again a downside. First, it only works since W2K,
> > second and worse, it only works with PAGE_READWRITE mapping. Neither
> > PAGE_READONLY, nor PAGE_WRITECOPY (aka MAP_PRIVATE) are allowed. Oh
> > boy. While PAGE_READONLY can be managed by changing the page protection
> > afterwards, I don't see a way to get it right for MAP_PRIVATE.
> So you mean that POSIX specifies that when a file is mapped larger
> than its size, as read only or private, the on disk file is actually
> extended? That would have been completely contrary to what I'd expect
> from those two modes. Otherwise, I don't understand this problem.
Read again. It's the contrary, as you'd expected. Briefly, POSIX allows
mappings beyond EOF w/o extending the file size, Windows doesn't.
There's a native NT flag called AT_EXTENDABLE_FILE which allows POSIX
semantics, but only starting with W2K, and only with PAGE_READWRITE, not
with PAGE_WRITECOPY page protection. PAGE_WRITECOPY is basically what
POSIX calls MAP_PRIVATE, so the AT_EXTENDABLE_FILE flag works only 50/50.
> Also FYI:
> You don't need more memory to enable /3GB on your machine.
Ok, thanks for the info.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin