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:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=hofvQtU
	fjgAQCmNW33ETkyeXWIHf+yU/6hRI74VuXBXrooLOUCi2LilP1gwFXyZkAui4T3+
	37rhpoIkie2kH2oUF++W+abCUpW4eJNOMHY04EffnLLiw2yeUlbV2+v8V+nfys15
	vznlPyhU1Ze2HEjMiyuwFO6a+XhESrIa4Y0I=
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:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type; s=default; bh=eJnLvAvzeU5y8
	8bnHLPqkm9aUH0=; b=Wns/bNgTHwBvregwOVd7QN033Dvd55rMDfczvkHsjqs6C
	Zq0lbaSeTaE7RDcauc/9uMcai+RUJ87TENQGZPL7mNY1eUSrPEJTY8lTHxBta8Kx
	fs/SpiCJZRU/x+QW13QdhbtQG8Q3FqEmUSQRY7NuMjy7K6eW2ItUbP9/h2oaHg=
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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1973
X-HELO:	mail-ot1-f50.google.com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GgL42GyJbjIXsfIeozoWp3wHNiSrByvIOaoP5F0vkk0=; b=f/Om1VYKeSbpBk1LHEDT0qGj779FylfhB4ovi21Kos9869AYE8W9LORLuJkYt+F2Ff bPhkEtjsBAlJMlPYNWyIvfU4WBWKQsXOd8azjiYJH2jMAGSjPVr0Tuwr2fAJ6/lsYGLQ XyHgtWhVMMOPk/QUhqq3CWVc3tb3h8ZposofxT4zJI4Z4Qv9GJZj3K04NuHLgRFTS8Bl aldYX+MqMTozfJCyJcYFPCpHfw32offcpW2DxupKqn4CxjsbmJkxw4ThlG7+cInkuZ2n LuZAfb4OWFwu9Of3jWrVaqXPqzhVhI/swTps/TsvGzJ3zXaYBPdM43ewPU7IqSwjCoiF lHbg==
MIME-Version:	1.0
References:	<CALLhcm4QGY+eP0_CRiSbJwQ12kOetvTK=6-AtC17x7d+QhGKTw AT mail DOT gmail DOT com> <20190603115456 DOT GG3437 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20190603115456.GG3437@calimero.vinschen.de>
From:	Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>
Date:	Tue, 4 Jun 2019 11:38:07 +0200
Message-ID:	<CALLhcm4qaha=XuBWEqag7QH1veA82UrB94emFtFMd26dZ_ZGZQ@mail.gmail.com>
Subject:	Re: possible problem with memory allocation using calloc/mmap/munmap
To:	cygwin AT cygwin DOT com, Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>

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

Thanks for the answer. It is appreciated.
I understand the problem and difficulty to resolve it. Maybe returning
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 from
that, so evaluation of this approach is up to you.
Thanks again.

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