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:reply-to:date:from:to:subject:message-id
	:mime-version:content-type; q=dns; s=default; b=q8F8WXjDNrL+dQwG
	2WENDdrtixGoC1RgHYUzuqVqpAgQwK8m1hoLtzbMGKxjKT9GbonpNB/suieEW3JG
	bTSnx5yxFvIVN+lY50Zbc3bBke22O+Th1EzkB3bqeAOZIlEgDHtHo4Ya1BruuYKB
	o4wPm3YLuAd5TNH8Pk2ijcy06r8=
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:reply-to:date:from:to:subject:message-id
	:mime-version:content-type; s=default; bh=ddEGP4+JGtQO/c0TKRPd8Q
	xMoh0=; b=dBANIjHwNOD7tcxwDzCxLTvOVoxVLgPU57XRdjgjPX9X3Tp53ADCaO
	YzUABJu+qkqmUj8pvbFG4sRfNoiItDr1jB2QAH00AnIRI/l+9/dhMnage5TwFRDu
	t9d/gs9CYPgav5llCP04GjW7PmRJeKoiHPEOQ2EyIB9xqvpgyPs78=
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-Virus-Found:	No
X-HELO:	localhost.localdomain
Reply-To:	cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-3.7 required=5.0 tests=AWL,BAYES_50,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
Date:	Wed, 8 Jul 2015 11:17:57 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.5
Message-Id:	<announce.20150708091757.GG2918@calimero.vinschen.de>
MIME-Version:	1.0
User-Agent:	Mutt/1.5.23 (2014-03-12)

Hi Cygwin friends and users,


I released another TEST version of Cygwin.  The version number is
2.1.0-0.5.

This test release needs some more 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 end of next week, 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.


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.

- Apparently on some Windows systems timezones differ in case
  from the standard.  Fix the tzset tool to check case-insensitive.
  Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00113.html

============================================================================

Changes compared to the previous test release:

o tzset now checks for timezone strings case-insensitve since,
  apparently, on some Windows systems the case differs from the
  defaults.

o Workaround a problem calling certain Cygwin functions from a signal
  handler running on an alternate signal stack:

  Some Cygwin functions may SEGV in a deliberate way, usually when
  testing invalid object pointers for validity, but the functions are
  supposed to recover from that and, for instance, return an EFAULT
  error.

  The problem here is, when running on the alternate stack, the 64 bit
  Windows exception handling will treat the alternate stack as
  "corrupted" and not call SEH handlers.  The workaround adds a
  vectored continuation handler to pick up the slack.

o Child stack allocation after fork has been rearranged.  It should
  be functional identical to the old version with a single change:

  If the stack you give to pthread_attr_setstack has been allocated
  with Windows functions, a subsequent fork will now very certainly
  fail.

  This functionality was partially broken for a longer time and nobody
  complained.  It's also hard to argue why a POSIX application using
  POSIX calls like pthread_attr_setstack should use, e.g, VirtualAlloc
  to allocate a pthread stack.  Use POSIX functions instead, e.g,
  malloc, mmap.

o Change how the child stack after fork gets extended to the size of
  the parent stack.  The old method poked into the stack in 4K steps
  to move the guardpage up and let the system commit the stack page-wise.
  The new method is to call VirtualAlloc to set up the stack in two
  simple steps.

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

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

- Raw text -