Resent-Date: Tue, 28 Nov 2000 22:45:35 -0500
Resent-Message-Id: <200011290345.WAA11040@delorie.com>
Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Date: Tue, 28 Nov 2000 11:45:58 -0800
From: "Zack Weinberg" <zackw@Stanford.EDU>
Resent-From: "R. Kelley Cook" <Kelley.Cook@home.com>
To: "cygwin@sources.redhat.com" <cygwin@sources.redhat.com>
Subject: Re: [PATCH] Problems with Cygwin mmap/munmap (mmap.cc)
Message-ID: <20001128114558.R2285@wolery.stanford.edu>
References: <200011281912.eASJCmf13405@plmlir5.mail.eds.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@sourceware.cygnus.com