From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120231 invoked by alias); 5 Jul 2015 21:48:30 -0000 Mailing-List: contact cygwin-announce-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-announce-owner@cygwin.com Reply-To: The Cygwin Mailing List Mail-Followup-To: cygwin-announce@cygwin.com Received: (qmail 115343 invoked by uid 89); 5 Jul 2015 21:34:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_20,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Date: Sun, 05 Jul 2015 21:48:00 -0000 From: Corinna Vinschen To: cygwin-announce@cygwin.com Subject: TEST RELEASE: Cygwin 2.1.0-0.4 Message-ID: <20150705213417.GH2918@calimero.vinschen.de> Mail-Followup-To: cygwin-announce@cygwin.com MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-07/txt/msg00010.txt.bz2 Hi Cygwin friends and users, I released another TEST version of Cygwin. The version number is 2.1.0-0.4. This test release needs some good testing! While the changes are still mostly interesting for developers, the under-the-hood changes will potentially impact existing applications. I'd like to release 2.1.0-1 in about two weeks, if possible. ==================================== tl;dr ================================== What's new: ----------- - Handle pthread stacksizes as in GLibc: Default to RLIMIT_STACK resource. Allow to set RLIMIT_STACK via setrlimit. Default RLIMIT_STACK to value from executable header as described on https://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx Default stacksize to 2 Megs in case RLIMIT_STACK is set to RLIM_INFINITY. - First cut of an implementation to allow signal handlers running on an alternate signal stack. - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE, MINSIGSTKSZ, SIGSTKSZ. - New API: sethostname. What changed: ------------- Bug Fixes --------- - Enable non-SA_RESTART behaviour on threads other than main thread. Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00260.html - Try to handle concurrent close on socket more gracefully Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00235.html - Fix fork failing after the parent recovered from a stack overflow. Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00384.html - Fix a crash on 64 bit XP/2003 when opening /proc/$PID/maps. ============================================================================ Changes compared to the previous test release: - getrlimit/setrlimit RLIMIT_STACK handling has been improved considerably. The old implementation returned wrong values and was generally useless. After some discussion with collegues working on glibc and the Linux kernel, I now implemented RLIMIT_STACK more closely aligned with the behaviour on Linux/glibc: - By default, getrlimit(RLIMIT_STACK) returns the value of the default stacksize taken from the Windows executable file header in rlim_cur, only slightly changed to account for guard pages. - setrlimit(RLIMIT_STACK) now works and stores the new values for later use. - The rlim_cur value is now used as default stacksize when creating pthreads. If rlim_cur is RLIM_INFINITY, the fallback stacksize is set to 2 Megs. - So far, if the application set the guardpage size via pthread_attr_setguardsize(), the thread stack was set up fully commited with a NOACCESS guardpage at the stack bottom. This approach wasted physical memory and it failed to trigger normal stack overflow exceptions. Cygwin now sets up a Windows-typical stack with only few commited pages and movable guardpages. However, this requires OS support if the guardpage area requested by pthread_attr_setguardsize() differs from the default OS guardpage size. This OS support is only available starting with Windows 2003 and 64 bit XP. 32 bit XP will still use the fully commited stack setup in this case. Another nail in XP's coffin... - If the pthread stack is not provided by the application (which is unusual anyway), the newly created stack will use a Windows compatible guardpage setup reflecting the setting from pthread_attr_setguardsize(), or the default OS-specific guardpage size. - When running a signal handler on the alternate signal stack, the handler is now called via a wrapper function. This wrapper function checkr if the SEGV was triggered by a STATUS_STACK_OVERFLOW. If so, it restores the last set of guard pages on the primary thread stack. If we don't do that, and if the handler longjmps, the stack stays broken and another stack overflow exits the process immediately with no chance to recover. If the handler simply returns, the wrapper restores the "broken" stack state to allow accessing the stack, then the exception handling triggers a SIG_DFL action for SIGSEGV: Create a stackdump and exit. Implementation details: - The alternate signal stack installed via sigaltstack is only valid for the current thread. Each thread must call its own sigaltstack. On pthread_create, the alternate signal stack setting of the calling thread is *not* propagated to the newly created thread. This follows current Linux semantics. - The alternate signal stack is a minimal stack. Certain datastructures used by Cygwin (_cygtls area) and Windows (on 32 bit: exception records) are not copied over to the alternate signal stack. The stack settings in the Thread Environment Block (TEB) are not reflecting the current alternate stack while running the signal handler. The TEB will still point to the original thread stack. This seems to work nicely in my testing, but there may be Windows functions which stop working in this scenario. - The volatile registers and the original stack registers are stored at the base of the alternate stack. If you screw this up while running the signal handler, your thread is doomed on return to the caller. I'd be grateful if curious developers would give this new sigaltstack implementation and the changed RLIMIT_STACK handling a whirl and report back if it's working for them as desired/expected. And if not, simple reproducers in plain C are most welcome in this case. Discussing aspects of this implementation may be best handled on the cygwin-developers mailing list or the #cygwin-developers IRC channel on Freenode. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat