From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75160 invoked by alias); 3 Jun 2019 11:55:05 -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 75151 invoked by uid 89); 3 Jun 2019 11:55:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-101.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=actions, Due, allocating, deallocation X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.187) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Jun 2019 11:55:03 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MScDh-1h9O9d0oht-00T09w; Mon, 03 Jun 2019 13:55:00 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id C4857A80653; Mon, 3 Jun 2019 13:54:56 +0200 (CEST) Date: Mon, 03 Jun 2019 11:55: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: <20190603115456.GG3437@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Stanislav Kascak , cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rWhLK7VZz0iBluhq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-06/txt/msg00011.txt.bz2 --rWhLK7VZz0iBluhq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1947 On May 3 13:33, Stanislav Kascak wrote: > Hello cygwin team, >=20 > I came across a problem with memory allocation/deallocation when > trying to compile and run tests of openldap under cygwin. >=20 > I created a test program to simulate sequence of actions. First a > bigger chunk of memory (>~262kB) is allocated using calloc(), then > mmap() is called with requested memory size much bigger than actual > file size. Subsequently, munmap() to free previous mmap(), and at the > end an attempt to access memory allocated with calloc(). That last > memory access is causing Segmentation fault. >=20 > It seems that when mmap() is called with length argument exceeding > size of file, only memory to fit that file is allocated. munmap() > however frees the full specified length. Since (at least on my > computer) big chunk of memory allocated by calloc() is located after > mmap() allocation, munmap() frees even memory of that calloc(). Ken's right. Due to the differences between mapping files on Windows vs. Unix, Cygwin can't map beyond the file size + the remainder of the last page. Cygwin tries to workaround that on 32 bit by allocating an anonymous mapping following the file mapping to keep the range free from other mappings. But on 64 bit this workaround doesn't work anymore because the OS is missing an (undocumented) flag which allows to create mappings on 4K boundaries, rather than just on 64K boundaries. I know this situation is unsatisfying, but I have no easy workaround to allow this. Cygwin could add the anonymous mapping on the next 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 the file length. If only 64 bit would allow 4K-aligned mappings :( Corinna --=20 Corinna Vinschen Cygwin Maintainer --rWhLK7VZz0iBluhq Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlz1CpAACgkQ9TYGna5E T6CgNw/+Pp3NJ3Pf+1QF9zg4XqQValBqzFjqSvSgb55l18l5GCbuGvOx1j6Q8eYm ueiknmuvBt3EUWGcsoOkO8u6ZUcgwlUlsCzbXbGvvd8k8jk+On2NT2DJ0G+Tv/jz 62G8hzzQ4NQkCoYN7DQhFX74tbYwPAWeQ8N3TTWvzG7/yRuqt/oe+cV1Qu44zmVw w2DyIHONLjPBu0HiRBwLrhIfhFt65qMkUVMlWvpQd71rcYBstdCSGQe1pGUntni3 cHvRkMZCUgi13esMDd0kd04S351LAS9EmuzROQPP52Ro9eAayTyJgs8mktK/7XBU dCxFPI5ZVUzNZNw2+WLVgzoK8BQMVIgCsgdxbPMT4fly07+DThg3dTtcy6UpLU05 21L+wckISCOHZmXKVse5kGTufj4xOKFheAGrnx2eL1HwqpfN7HG0Kaz1vQ9KidiQ Cim1g4Jh3q82zjK9ThrYO3UlWGUIJa55WcX077HnUAjK/NYL6njac235J1bfSovK 5P0UDNOgB65qRYEJWULzKpI/MQ3nfq27T/NIob2b8W+sJpFYQ+bsGQWgb1MSBkF/ zoP0MonD4Km6c/xAbi1WC+o8nYNl3eiWCp0a3Oi958c/F1MDHOh1ctRcGjHiaIUw tZjziC6Qs8vtI0oElC9Q0LtryTtDlvSKdUUzeidQZ/LVsfiNvug= =X4e8 -----END PGP SIGNATURE----- --rWhLK7VZz0iBluhq--