From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48557 invoked by alias); 5 Jun 2019 18:23:21 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 48550 invoked by uid 89); 5 Jun 2019 18:23:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-101.8 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=H*F:D*cygwin.com X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.134) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Jun 2019 18:23:19 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MVNF1-1hAE682xMt-00SLkM; Wed, 05 Jun 2019 20:23:15 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 1CD43A8034C; Wed, 5 Jun 2019 20:23:15 +0200 (CEST) Date: Wed, 05 Jun 2019 18:23:00 -0000 From: Corinna Vinschen To: Stanislav Kascak Cc: cygwin@cygwin.com Subject: Re: possible problem with memory allocation using calloc/mmap/munmap Message-ID: <20190605182315.GZ3437@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Stanislav Kascak , cygwin@cygwin.com References: <20190603115456.GG3437@calimero.vinschen.de> <20190604131836.GS3437@calimero.vinschen.de> <20190604144948.GT3437@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xMJbWctQEcNQiBqK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-06/txt/msg00053.txt.bz2 --xMJbWctQEcNQiBqK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3936 On Jun 4 18:01, Stanislav Kascak wrote: > > > > > > > It seems that when mmap() is called with length argument exce= eding > > > > > > > size of file, only memory to fit that file is allocated. munm= ap() > > > > > > > however frees the full specified length. [...] > > > > > > [...] > > > > > > I know this situation is unsatisfying, but I have no easy worka= round > > > > > > to allow this. Cygwin could add the anonymous mapping on the n= ext > > > > > > 64K boundary on 64 bit, but that would result in a hole in the = mapping > > > > > > which seemed like a rather bad idea when porting mmap to 64 bit. > > > > > > > > > > > > Ken's also right that munmap is doing the right thing here. If > > > > > > anything's wrong, it's mmap's workaround for mappings beyond th= e file > > > > > > length. If only 64 bit would allow 4K-aligned mappings :( > > > > > > > > > > Thanks for the answer. It is appreciated. > > > > > I understand the problem and difficulty to resolve it. Maybe retu= rning > > > > > an error from mmap (and putting a comment to code for its reason) > > > > > would be sufficient. mmap caller could just adjust requested > > > > > allocation size to file size. Without error, caller has no way of > > > > > knowing memory was not allocated and segfault is then thrown in an > > > > > unrelated memory segment which makes the root cause hard to track > > > > > down. But, I do not know all the implication that could result fr= om > > > > > that, so evaluation of this approach is up to you. > > > > [...] > > > > Eventually Cygwin adds another mapping to fullfill the entire mappi= ng > > > > request: > > > > > > > > |-- file 4K --|-- filler 60K --|-- filler 192K --| > > > > > > > > The problem on WOW64 and real 64 bit is that it's impossible to map > > > > the first filler. However, this area in the VM will *never* be > > > > allocated by other application functions due to the allocation > > > > granularity of 64K! > > > > > > > > So my workaround for 64 bit and WOW64 is to just skip allocating the > > > > first filler: > > > > > > > > |-- file 4K --|-- THE VOID 60K --|-- filler 192K --| > > > > > > > > The advantage is now that the following munmap of 256K will only > > > > unmap the map for the file and the filler, but not the region you > > > > calloced before, which formerly was accidentally mapped to the > > > > filler region. This just can't happen anymore now. > > > > > > > > Would that be feasible? If so I can push my patch and create a > > > > developer snapshot for testing. > > > > > > Two questions arise when I'm thinking about workaround solution: > > > - what happens if caller tries to write to |-- THE VOID 60K --|. Since > > > this is unallocated, would there be a segfault? > > > > Accessing the VOID would raise SIGSEGV, while accessing the filler > > raises SIGBUS. The latter is also used to implement MAP_NORESERVE, > > which the VOID can't support. >=20 > I played around a bit and I can confirm it would be consistent with > current behavior: > memwrite <0 - filesize) - no error, written to file > memwrite memwrite <4k, 64k) - SIGSEGV > memwrite <64k, mmap alloc size) - SIGSEGV or another mem alloc > overwrite (depending on whether there is another allocation) > With workaround last line would be fixed to SIGBUS (along with proper > allocation length). I believe this is completely OK. >=20 > > > > > - is it possible that some subsequent mem alloc request would return > > > region from |-- THE VOID 60K --| which could again cause segfault > > > after munmap? > > > > No, as stated above. Allocations are restricted to Windows' 64K > > allocation granularity. >=20 > I apologize. I missed that sentence. So, your workaround seems fine. Please try the latest snapshot from https://cygwin.com/snapshots/ Just replacing the Cygwin DLL is sufficient. Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer --xMJbWctQEcNQiBqK Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlz4CJIACgkQ9TYGna5E T6CGHA/9HrlEZdc5cHDBNQgSbrqUgSaK3d+lw7TnXxGa2mUk4oTdLmqu5ozHj+w7 AcD2UFeILocu3AZ50B19N968ko9Y6Jya/f5Dud04lvzmdOTycsU8mOpqM4/o/PLb BompBgo76C+4DsRctbWzNtRHawqp70js2/n3pWOZi70e+9bA1fDXO2Lxn62MRUQi 7QBnphA4A5Cq1qeinyTXZgQckbaxGxK5IQUfjrODk85pBOGHap2Ql2ZcLW/W3ehq E0Z4N9HktmpHjtiUMteCTh9xt+o44+ZHrgKcgtlpSFsmvwpjZF1+kaRCfhFhcUtr UYe+fcWq5kKBUujOsDtg1IIZXzBfOegtcbam9fghenUyKPS0O7C7i/QL4E/55EG1 QOGcL85c8ORvaiTvrx27PsnR520s6fiegIblWrWQ6jgFLv518a8LhitCxywxZNlY p0jgcR/kJQx67dT38NWFpQ3Ip6JGmhq8hKRa+96llyWvWmchzIZRzr+ddhdalg5H zznmzOxdxMv1jrE1jic6+Uiagc24W7r6kHf7/h0+LHvTaCrMIUfUPhY6qKLTLXHD bVnUaXOFB5f7jzcZTk2/L87N540Mwx98IRgb+WHJI0kmsss3jT0F5yhQ+qD5AdAs Kii9nMCaag3fovNCna56B7wbnTsew7qY7taR1WvtfRp5GMLdIYA= =nlk7 -----END PGP SIGNATURE----- --xMJbWctQEcNQiBqK--