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: List-Archive: List-Post: List-Help: , 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" Resent-From: "R. Kelley Cook" To: "cygwin AT sources DOT redhat DOT com" X-Original-To: Kelley Cook X-Original-Cc: Cygwin Developers , "Billinghurst, David (CRTS)" 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