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=MRlAe3V
	UALSHSHnoFTzP9tngFC0ijeQcO5QCKHY7hHn6dACVNjEaivZP25k4qto+iklX6pI
	YLNkZdLuGggtS6vxD2wCyNSx7ABoxGJ2/8WUIVRlJtiw6LPgRMKzV1ywVH/lt4hr
	Vc8bBaQzibHTZ/9drtpcnnXD2DKCOvoZYRJ8=
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=wqHkKqJ0M1yzM
	J9amN51ivRWhyI=; b=Ldt1dTiGkn5rIthaHiQUzt6O2x7B4zX4Quu9O2UfeHgdM
	KCj8W94A9M/lyZME+Z1e1djRBJJTYxkyJ8eUBfx2Qm3Je7Rgg1PldbUlB9KksrMQ
	Z91whIE/kxpVS1y7WeyhqWeNWrAF1fIKOXls9EjuhYEKoI2pRPc9Cn2/f+ZxIw=
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=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.1 spammy=HX-Languages-Length:4324
X-HELO: mail-ot1-f67.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=FoJbAiddGlM/Tf4jOmuG3lnewJhfOY/dac0FjJcbzEM=;        b=A7QrpEB2sMLyR/K84KZazzt4hiMS0GWqSsbA9cIB87PSfDYWaA7GKDchBNbPGt8o6f         UqqE2zopl+WUTiNaIfscvqmWYluY7QXkYy9HNuh08fimQoFF0KD8hGRAXzbBwaGhgeaa         K+rq0q4KKOob7/uVcsxKFIGKRypxnTQryPJhEoJ1oM1xQ0/Y+8F7Xhb5Yff+QPJgc0Mv         3GUoB88L2HsYEWNKYzm68p7JPHT6gdSsz0BKb1mu8VHalDkd9Cq4mP80C93zOdQBSFad         wmCjz2IYKzi0wbi5eDKIvuxwpfZ2XzhD7EGHhakvIw4ahJMeHNJhql2UVsmecgMxHRCZ         brlg==
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> <CALLhcm4qaha=XuBWEqag7QH1veA82UrB94emFtFMd26dZ_ZGZQ AT mail DOT gmail DOT com> <20190604131836 DOT GS3437 AT calimero DOT vinschen DOT de> <CALLhcm4sHGmFwki+RuUOUA-GfnXzmOUX4Tr8Es-=291Bo+A4dg AT mail DOT gmail DOT com> <20190604144948 DOT GT3437 AT calimero DOT vinschen DOT de> <CALLhcm5rKTVCD3Hb69CzC-94-86-PRpUofA9OEAy_mci1GnHQA AT mail DOT gmail DOT com> <20190605182315 DOT GZ3437 AT calimero DOT vinschen DOT de>
In-Reply-To: <20190605182315.GZ3437@calimero.vinschen.de>
From: Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>
Date: Thu, 6 Jun 2019 15:13:56 +0200
Message-ID: <CALLhcm6oXXEdvLgjoWkzDosqces7aaBd9gtBx=zq+VRnPTFA3w@mail.gmail.com>
Subject: Re: possible problem with memory allocation using calloc/mmap/munmap
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="UTF-8"

> > > > > > > > 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. [...]
> > > > > > > [...]
> > > > > > > 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.
> > > > > [...]
> > > > > Eventually Cygwin adds another mapping to fullfill the entire mapping
> > > > > 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.
> >
> > 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 <filesize - 4k) - no error, no file change
> > 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.
> >
> > >
> > > > - 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.
> >
> > 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.

My test programs work fine and also openldap crash that led me to this
issue is gone (openldap tests still fail, but on a different place
after the one above and now with a SIGBUS which already gives a good
hint as to where to look).
I think your patch works quite well. Thanks a lot.

Stanislav Kascak

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