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/
