X-Spam-Check-By: sourceware.org
Date: Sat, 13 Jan 2007 00:22:07 -0800
From: Christopher Layne <clayne AT anodized DOT com>
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> <Pine DOT CYG DOT 4 DOT 58 DOT 0701050959060 DOT 2704 AT PC1163-8460-XP DOT flightsafety DOT com> <Pine DOT CYG DOT 4 DOT 58 DOT 0701051054010 DOT 280 AT PC1163-8460-XP DOT flightsafety DOT com> <Pine DOT CYG DOT 4 DOT 58 DOT 0701051144030 DOT 2880 AT PC1163-8460-XP DOT flightsafety DOT com> <20070105182234 DOT GC12776 AT calimero DOT vinschen DOT de> <Pine DOT CYG DOT 4 DOT 58 DOT 0701051237090 DOT 2880 AT PC1163-8460-XP DOT flightsafety DOT com> <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: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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/