delorie.com/archives/browse.cgi | search |
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=u7WnaGx | |
Gys43VP+wKIhsNSLpX8qWlsSoGxtc14ZTa09s2TKXvbJ6ZRlaqRDjp/vLyJZq05Y | |
adcBrxecX9j9q4TuXoP9KP8awZznYYO1kKfzDPDUoDOu1CsrBqx/jwU7+L8C2tre | |
NHosCElWb2xVLEofQFVjjHRehxWm3vtYSodo= | |
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=pvaxeANSPOPNx | |
IrneZCv3SBj6Cw=; b=ql2ik1H5NV4MXvqWZ4Gff+8sswjxvqfNkvGoZAjYkvuT6 | |
ECZYPhSKb4pEx6H4EBKWiRFxhdP1NGwxlNv3jVlG2XxwnNILpdsN/EYgxx0/hno1 | |
dws9k9QC46JiBHK/ehj577oI8fT/6bmyRTwwMj9qOhdy4U2jtF1r2UDGrlcX9E= | |
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.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.1 spammy=played |
X-HELO: | mail-ot1-f65.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=ONBfx58A1h3wbe02SABZ29zX8J4jb8O/7EhLAYkpvgY=; b=Fn3RCOU84g6psLQIXCg4K7paxs0TL95Ka/kka9mrNkgymm+EGIbeDGHwhbatnmHmX/ 9EGopxlNrALYri7U43dGwt+OUlsvGZmqE/zN+NXi9RD7JP4+YYzFEyjojnPA/DStBmvq rsn5MuXzIs12qcdpv/QoFEBh+mbsLvLSxPVvjMyllo5ctM+xSedqVv+9067U0xXqqHwj 0s2JJPdM8MexMMSwhTGhqD4mVap8ylkiA3MQ/m4Kfey4ch/pNaLTferWvaIfrtvYO52q IL0iWo8yZkhKyfciF3NB0maY0inxgq2xIb2HsovTDrTkoCOXzCCvR/D1KBoW4F62/Ljf eLBw== |
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> |
In-Reply-To: | <20190604144948.GT3437@calimero.vinschen.de> |
From: | Stanislav Kascak <stanislav DOT kascak AT gmail DOT com> |
Date: | Tue, 4 Jun 2019 18:01:53 +0200 |
Message-ID: | <CALLhcm5rKTVCD3Hb69CzC-94-86-PRpUofA9OEAy_mci1GnHQA@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. [...] > > > > > [...] > > > > > 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. -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |