Resent-Date: Tue, 28 Nov 2000 22:45:35 -0500
Resent-Message-Id: <200011290345 DOT WAA11040 AT delorie DOT com>
Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Tue, 28 Nov 2000 11:45:58 -0800
From: "Zack Weinberg" <zackw AT Stanford DOT EDU>
Resent-From: "R. Kelley Cook" <Kelley DOT Cook AT home DOT com>
To: "cygwin AT sources DOT redhat DOT com" <cygwin AT sources DOT redhat DOT com>
X-Original-To: Kelley Cook <Kelley DOT Cook AT home DOT com>
X-Original-Cc: Cygwin Developers <cygwin-developers AT sources DOT redhat DOT com>,
        "Billinghurst, David (CRTS)" <David DOT Billinghurst AT riotinto DOT com>
Subject: Re: [PATCH] Problems with Cygwin mmap/munmap (mmap.cc)
Message-ID: <20001128114558.R2285@wolery.stanford.edu>
References: <200011281912 DOT eASJCmf13405 AT plmlir5 DOT mail DOT eds DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200011281912.eASJCmf13405@plmlir5.mail.eds.com>; from Kelley.Cook@home.com on Tue, Nov 28, 2000 at 02:12:37PM -0500

On Tue, Nov 28, 2000 at 02:12:37PM -0500, Kelley Cook wrote:

> loc = mmap (NULL, 1048576, PROT_READ | PROT_WRITE, 
>             MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> munmap (loc + 786432, 262144)
> munmap (loc, 524288)
> 
> and still have a valid 256K map @ loc+524288.
> 
> This fails under cygwin since munmap is a thunk into the Win32's API 
> UnmapViewOfFile which does not take a length parameter and therefore always 
> frees the amount allocated on the call to MapViewOfFile/MapViewOfFileEx.  
> So under Cygwin, the first munmap call would fail and the second one 
> frees the entire range.  The first causes a memory leak and the second
> will likely later lead to a segfault.

Aha, this tells me how to write a suitable autoconf test for the buggy
version.  The test program I had wasn't thorough enough.

> FWIW, it doesn't attempt to emulate another *nix mmap/munmap possibility,
> which is using one munmap with a double length to unmap two consecutive 
> mmapped regions.  I personally don't think this is a good idea, so I 
> just ignored that case.  The munmap call properly fails with EINVAL if it
> is attempted which at least will let the programmer know that it is 
> unsupported.

Whether it's a good idea is arguable, but GCC uses this behavior too.
If cygwin doesn't support it that will be another memory leak (though
not a segfault).  Note it also assumes munmap cannot fail, which I
happen to think is a reasonable stance for resource deallocation
primitives.

I might point out that we only want these things for mmap of anonymous
memory.  If Cygwin used VirtualAlloc instead of CreateFileMapping with
an invalid handle to implement anonymous mmap, then both behaviors
would be implementable easily.  (I don't know if this would interfere
with cygwin's brk() implementation, though.)

zw

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com