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:from:to:cc:subject:date:message-id:references
	:in-reply-to:content-type:content-id:content-transfer-encoding
	:mime-version; q=dns; s=default; b=iP6qFGZLfYpEC6rNKzP3DOeyMALAp
	7Qr3o6SrMBrIkKkwqO+RMgA8jdk1CHghhRkGIIzQjbx8oF1JdGzWXgA9Vu+56qeb
	XIdqgwX3QjonFrOqfUICUgkUXOl/IybTYdVzDCW2qIKPZx+WWEyA+p3G3Pk0/DIi
	F4kkgjtUsCuLv4=
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:from:to:cc:subject:date:message-id:references
	:in-reply-to:content-type:content-id:content-transfer-encoding
	:mime-version; s=default; bh=vbnAF+PIEmmmoXwzZ+LIoitCptA=; b=CbW
	xkmoQyTNy4+Q1o7Vpl/s2MLl8lE+HGuhlvKKI0w12ZxojghSAcl1MeMFDiq74yBX
	ntrqukFS9l+hGC6/YVa62/FuI6afsAu+8RUvoz6pKMQ7I5f41c2QcVkFdmSo8ziA
	Fas652+xlwuThnmcVjIu2nEMGLGQNr3RWHYJEPKM=
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=-1.6 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=continuing, vacation, subsequently, definitive
X-HELO:	NAM05-CO1-obe.outbound.protection.outlook.com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rCkV+crrE9YoibjABlrOiMOqE8mbr28kMRuqumVVehU=; b=Qxan4cBwITnut9VnE4SrczPjYdDHCN62KJMF+L/oUngFiuTOyWymS8ous1ZVthG8Xg0D1dC8a/Fp5OISNuDnweJp0aIV75jKls+tV4rD1wK8wJmURF9S+/PGOgH1LkHd9/s0VdKPDHyE6jQYoabytCQHQ6eIjcqHmyUMBrcbAHY=
From:	Ken Brown <kbrown AT cornell DOT edu>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
CC:	Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>
Subject:	Re: possible problem with memory allocation using calloc/mmap/munmap
Date:	Mon, 20 May 2019 22:26:40 +0000
Message-ID:	<949f0c5f-9806-a861-6a48-089b83aab032@cornell.edu>
References:	<CALLhcm4QGY+eP0_CRiSbJwQ12kOetvTK=6-AtC17x7d+QhGKTw AT mail DOT gmail DOT com>
In-Reply-To:	<CALLhcm4QGY+eP0_CRiSbJwQ12kOetvTK=6-AtC17x7d+QhGKTw@mail.gmail.com>
user-agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
authentication-results:	spf=none (sender IP is ) smtp.mailfrom=kbrown AT cornell DOT edu;
x-ms-oob-tlc-oobclassifiers:	OLM:6430;
received-spf:	None (protection.outlook.com: cornell.edu does not designate permitted sender hosts)
x-ms-exchange-senderadcheck:	1
MIME-Version:	1.0
X-MS-Exchange-CrossTenant-mailboxtype:	HOSTED
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id x4KMQshM003762

On 5/3/2019 7:33 AM, Stanislav Kascak wrote:
> I came across a problem with memory allocation/deallocation when
> trying to compile and run tests of openldap under cygwin.

Corinna can give you a definitive response when she returns from vacation, but I 
looked at the code and have a few comments.

> 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.
> 
> It seems that when mmap() is called with length argument exceeding
> size of file, only memory to fit that file is allocated.

That's correct.  The following comment in mmap.cc:1100 explains why: "don't map 
beyond EOF, since Windows would change the file to the new length, in contrast 
to POSIX."

> 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().

I think munmap does exactly what it's supposed to do according to Posix, which 
is "remove any mappings for those entire pages containing any part of the 
address space of the process starting at addr and continuing for len bytes."  In 
your case, that includes the memory allocated by calloc, which uses mmap.

I'm not sure what openldap is doing in your actual use case, but is there really 
a good reason to call mmap with requested size much bigger than the actual file 
size?  After all, you can never access that extra memory.  Posix says, 
"References within the address range starting at pa and continuing for len bytes 
to whole pages following the end of an object shall result in delivery of a 
SIGBUS signal."

But let's wait and see what Corinna says.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -