Mail Archives: cygwin/2007/01/13/03:22:34
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.
>
>
> Corinna
The real question I have is why was what *should* have worked, not working?
-cl
--
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/
- Raw text -