From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128746 invoked by alias); 28 Feb 2019 11:50:44 -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 128735 invoked by uid 89); 28 Feb 2019 11:50:43 -0000 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.2 spammy=wondered, wait!, personally, month X-HELO: mail-io1-f41.google.com Received: from mail-io1-f41.google.com (HELO mail-io1-f41.google.com) (209.85.166.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Feb 2019 11:50:42 +0000 Received: by mail-io1-f41.google.com with SMTP id p17so16310450iol.7 for ; Thu, 28 Feb 2019 03:50:41 -0800 (PST) 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=ePyhyNYOIJZl10BwlRUwRPqMl+oBAs/Gm0yBLd8MjUk=; b=btfp6oy5SIrknoqc68byToMoMsrrF6a2t7bwjO3SMBKWXwG+J3w9Uylfgl5D9Pj8TW 9H7Yu5VmBUeqljwHK2nOZCcfIwjzZYeUTX0oJHCbETJpq9v4Cm+bF/LX6NDbuPjlr8ge +Bo5hb4IJ0bPhZ+HtfdS+VDh2HJ3heQe8xSQnxeKJZubHXWp+4Limk6s2BRXgT9qqG7x I4euKtCO/5nhMIjps4dkT3TprzG1ZrloYUgRYYY6JiLaOAYf2FKv2PELrYFgerYefCf8 hpMgV0iaxCGJHmeXaVylglxmUPiHxiMR+JHwgyMSIW1/DXjwbTR2yQaRh6lqb0zabnAY oWVA== MIME-Version: 1.0 References: <20190227161712.GB4133@calimero.vinschen.de> In-Reply-To: <20190227161712.GB4133@calimero.vinschen.de> From: "E. Madison Bray" Date: Thu, 28 Feb 2019 13:12:00 -0000 Message-ID: Subject: Re: Consider exposing mmap_is_attached_or_noreserve To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00498.txt.bz2 On Wed, Feb 27, 2019 at 5:17 PM Corinna Vinschen wrote: > > On Feb 27 16:38, E. Madison Bray wrote: > > Hello, > > > > A very technical request regarding Cygwin internals: In mmap.c there > > is a function mmap_is_attached_or_noreserve(void *addr, size_t len) > > which is called from Cygwin's exception handler in the case of a > > STATUS_ACCESS_VIOLATION. > > > > This is called in case an access violation occurs in memory that was > > allocated with Cygwin's mmap() with the MAP_NORESERVE flag, and allows > > us to commit the relevant pages when they are accessed. > > > > After a successful call of mmap_is_attached_or_noreserve(), the Cygwin > > exception handler returns with ExceptionContinueExecution. > > Unfortunately, if the application happens to have a Vectored Continue > > Handler registered which happens to do something in the case of > > STATUS_ACCESS_VIOLATION (see [1]) there is no obvious way to tell if > > we're handling this sort of case. > > > > Normally this isn't too much of a problem: E.g. we could just check > > the address that caused the access violation and see if its status is > > now MEM_COMMIT (i.e. Cygwin ran its exception handler and all is > > good). However, due to the bug described in [1], if an exception > > occurs in code running on a sigaltstack, the Cygwin exception handler > > isn't run. > > > > This makes for a tricky to handle use case: What if some code in a > > signal handler function tries to access uncommitted memory in a > > MAP_NORESERVE mmap? It's probably an unusual, undesirable case, and I > > haven't personally encountered it *yet*, but I could imagine some > > cases where it might happen. > > > > In order to handle such a case it might be nice if > > mmap_is_attached_or_noreserve were able to be called by user code, > > perhaps as a new cygwin_internal(...) call. I'd happily provide a > > patch, but I fear this might be an X/Y problem that I'm not seeing. > > Honestly, I'm not overly keen to expose this stuff. Wouldn't it > make more sense to fix Cygwin's sigaltstack implementation to handle > these cases gracefully? You're apparently not shy working with > Windows exception handling. Patches more than welcome! I'm not > happy not having found a solution to this problem :} I can theoretically imagine a case where might be a problem totally outside the context of the altstack issue: e.g. maybe a cygwin application that has to link with a native Windows DLL that happens to register some vectored continue handler that does something with STATUS_ACCESS_VIOLATION exceptions. Of course, absent a real example I wouldn't push for it. I completely agree it would be better to have a solution to the actual problem. > Oh, wait! Maybe there is a simple solution. Patch 9a5abcc896bd > added a single line > > exception protect; > > to the pthread::thread_init_wrapper method. > > What if adding the same line to the altstack_wrapper function > would help for altstack as well? You know, I actually noticed this just recently, because I noticed that pthreads also run on a stack allocated by Cygwin, and I wondered how exception handling would work in that case. I think I was looking at it in the context of the thread last month that resulted in that fix, but I forgot to ask you if this could work for the altstack issue as well. > Can you test this? I'll give it a try and report back with a patch if it works. The biggest risk is if a stack overflow happens while running on the altstack--in this case even the Cygwin exception handling could fail and the application will just crash. But for other, less extreme cases having this would be better than nothing. -- 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