X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=L9QlbLF5Q3O1i/PYN/hP/4x4PNJzsaK2JoE605Wk2acvzMYidIKE1
	I/wNYbswFCi7N9D2e37lKx8xopq0ihgwwL7BnE6lxBiswzzscPufmISiX0ffOmRg
	TpWe+nSzrFeakmb4LjnijBRUazWFicy5uTVr71xgu//7bVFKtQ5hJg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=QnGmhpXqXBnkvviPRDMhv7h+rIs=; b=K1wrxhQfDmTVnJg5j+IDk4+/Medc
	Xn8f0+7OPEJN+RFt3zSGizY4LxdrAoPZoF1kBVoGZgPcHOaqr83qGTPkred5svaB
	HLOVOCReKcVdeqrp+Hu4KJuveVgj6KhuCjY03+wwcKSMzBVU9ULq9npCgg3ZAkgy
	GhfwAbAEOxkTCCQ=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
Date:	Mon, 3 Jun 2019 13:54:56 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>
Cc:	cygwin AT cygwin DOT com
Subject:	Re: possible problem with memory allocation using calloc/mmap/munmap
Message-ID:	<20190603115456.GG3437@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>, cygwin AT cygwin DOT com
References:	<CALLhcm4QGY+eP0_CRiSbJwQ12kOetvTK=6-AtC17x7d+QhGKTw AT mail DOT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<CALLhcm4QGY+eP0_CRiSbJwQ12kOetvTK=6-AtC17x7d+QhGKTw@mail.gmail.com>
User-Agent:	Mutt/1.11.3 (2019-02-01)

--rWhLK7VZz0iBluhq
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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"

-----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--

- Raw text -