X-Spam-Check-By: sourceware.org Date: Sat, 13 Jan 2007 00:22:07 -0800 From: Christopher Layne To: cygwin AT cygwin DOT com Subject: Re: 1.7.0 CVS mmap failure Message-ID: <20070113082207.GE14559@ns1.anodized.com> References: <20070105095752 DOT GB28768 AT calimero DOT vinschen DOT de> <20070105182234 DOT GC12776 AT calimero DOT vinschen DOT de> <20070105192302 DOT GD12776 AT calimero DOT vinschen DOT de> <20070110095345 DOT GL23638 AT calimero DOT vinschen DOT de> <20070111063859 DOT GF19638 AT ns1 DOT anodized DOT com> <20070111094647 DOT GQ23638 AT calimero DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070111094647.GQ23638@calimero.vinschen.de> User-Agent: Mutt/1.5.11 X-Assp-Spam-Prob: 0.00000 X-Assp-Whitelisted: Yes X-Assp-Envelope-From: clayne AT ns1 DOT anodized DOT com X-Assp-Intended-For: cygwin AT cygwin DOT com X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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/