X-Spam-Check-By: sourceware.org
Date: Fri, 5 Jan 2007 19:22:34 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.0 CVS mmap failure
Message-ID: <20070105182234.GC12776@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <Pine DOT CYG DOT 4 DOT 58 DOT 0701041715140 DOT 3520 AT PC1163-8460-XP DOT flightsafety DOT com> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.CYG.4.58.0701051144030.2880@PC1163-8460-XP.flightsafety.com>
User-Agent: Mutt/1.4.2.2i
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 Jan  5 11:52, Brian Ford wrote:
> Here is an interesting strace comparison:
> 
> Non-/3GB:
>  4978   26688 [main] mmaptest 2284 MapViewNT: 7FFA0000 =
> NtMapViewOfSection (h:6EC, addr:0, len:28237, off:0, protect:80, type:0)
> [snip]
>     60   27113 [main] mmaptest 2284 MapViewNT: 7FFA7000 =
> NtMapViewOfSection (h:6E8, addr:7FFA7000, len:36864, off:0, protect:80, type:0)
>   126   27239 [main] mmaptest 2284 mmap64: 0x7FFA0000 = mmap()
> 
> /3GB not large address aware:
>   183   22192 [main] mmaptest 2856 MapViewNT: 7FFF0000 =
> NtMapViewOfSection (h:6F0, addr:0, len:28237, off:0, protect:80, type:0)
> [snip]
>    68   22648 [main] mmaptest 2856 MapViewNT: 0 = NtMapViewOfSection
> (h:6EC, addr:7FFF7000, len:36864, off:0, protect:80, type:0)
>    44   22692 [main] mmaptest 2856 seterrno_from_win_error:
> ../../../../cygwin/winsup/cygwin/mmap.cc:1707 windows error 487
>    46   22738 [main] mmaptest 2856 geterrno_from_win_error: windows error
> 487 == errno 22
>    41   22779 [main] mmaptest 2856 __set_errno: void
> seterrno_from_win_error(const char*, int, DWORD):310 val 22
>    79   22858 [main] mmaptest 2856 __set_errno: void* mmap64(void*,
> size_t, int, int, int, _off64_t):1251 val 12
> --- Process 2856, exception C0000008 at 7C90EB74
> 13337   36195 [main] mmaptest 2856 mmap64: 0xFFFFFFFF = mmap()
> 
> /3GB large address aware:
>   191   22246 [main] mmaptest 3420 MapViewNT: AEFA0000 =
> NtMapViewOfSection (h:6EC, addr:0, len:28237, off:0, protect:80, type:0)
> [snip]
>    66   22676 [main] mmaptest 3420 MapViewNT: AEFA7000 =
> NtMapViewOfSection (h:6E8, addr:AEFA7000, len:36864, off:0, protect:80,
> type:0)
>   126   22802 [main] mmaptest 3420 mmap64: 0xAEFA0000 = mmap()
> 
> The second MapViewNT call is filling out the padding to a 64k boundary.
> It appears in the problem case that the system doesn't like the 0x7FFF7000
> address.  Any idea why?

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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/