This is the mail archive of the
mailing list for the Cygwin project.
Re: 1.7.0 CVS mmap failure
On Thu, Jan 11, 2007 at 10:46:48AM +0100, Corinna Vinschen wrote:
> > This works on my machine now. So previously why was the former method
> > failing, do you think?
> Er... haven't we discussed this at great lengths in this thread?
Yes, but did we ever establish a reason that was actually solid in foundation?
The reason I ask again what may be "obvious" is because of the still-present
ambiguity back here:
> That's not visible in the above strace. Since the pagesize is supposed
> to be == allocation granularity == 64K, but file mappings are aligned
> to the next page boundary beyond EOF (sigh), Cygwin tries to accomodate
> the expectations of the application by appending an anonymous mapping
> to fill the whole mapping up to 64K. In the failing case this should
> still work, since 0x7fff7000 + 0x9000 (36864 dec) == 0x80000000, so the
> mapping should fit into the usual 2 Gig address space. Why Windows
> fails to do it, I have no idea. The error code 487 means invalid
> address which might mean "already taken" address, but that's not visible
> in the strace. To figure that out would require to add a bit of
> VirtualQuery code to mmap and add appropriate debug output.
> 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. However, it's not quite clear if that really would
> help since the above *should* have worked to the best of my knowledge.
The real question I have is why was what *should* have worked, not working?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html