From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118816 invoked by alias); 4 Jun 2019 16:02:08 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 118809 invoked by uid 89); 4 Jun 2019 16:02:08 -0000 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 Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Jun 2019 16:02:06 +0000 Received: by mail-ot1-f65.google.com with SMTP id n14so20055632otk.2 for ; Tue, 04 Jun 2019 09:02:06 -0700 (PDT) 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: <20190603115456.GG3437@calimero.vinschen.de> <20190604131836.GS3437@calimero.vinschen.de> <20190604144948.GT3437@calimero.vinschen.de> In-Reply-To: <20190604144948.GT3437@calimero.vinschen.de> From: Stanislav Kascak Date: Tue, 04 Jun 2019 16:02:00 -0000 Message-ID: Subject: Re: possible problem with memory allocation using calloc/mmap/munmap To: cygwin@cygwin.com, Stanislav Kascak Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-06/txt/msg00029.txt.bz2 > > > > > > 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 > > - 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