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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=yvfLPvBotqM/wfn6YVUL+pGThtUdWe2INvKylAoPFqvL/IUkPSbP9
	S8dGAfsNL5OSGrLH2E2cJEaA9OfQK0XkFS3jGz1/fEoxe15d1a/yTDlNHbcaj3ML
	eLNRexSDbevuBB9+5eBcWz5Vjj/LOGWd4JEio4jrna9pAGJOQtVSSo=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=AIWyMgTfAQ60/5cBwV3l+MgOrVQ=; b=Zy8Ga+bBUKvQMEqPLYJZo+sKyL1c
	dLgzQiJ4ovokwbFpfe3dwJKHaLnWzdEMPxudkBag5D/D1AwGnH3xCD73Hh0e/f5K
	/i5AAjakeSDORBtCXC9H6V1U5Nmn0TTiMJykwUrt5hhxdPO+NIBNbHHTcdBeDAcH
	cZNDaSOjSRg0aIU=
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-Spam-SWARE-Status:	No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Wed, 1 Jul 2015 15:57:49 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
Message-ID:	<20150701135749.GN2918@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20150626141437 DOT GV31223 AT calimero DOT vinschen DOT de> <558D62D7 DOT 8010709 AT cornell DOT edu> <20150626153647 DOT GX31223 AT calimero DOT vinschen DOT de> <558D8409 DOT 2000400 AT cornell DOT edu> <20150626200512 DOT GA30636 AT calimero DOT vinschen DOT de> <558DD1F3 DOT 4010301 AT cornell DOT edu> <20150627145259 DOT GB23036 AT calimero DOT vinschen DOT de> <20150630195547 DOT GG2918 AT calimero DOT vinschen DOT de> <5592F86E DOT 8070803 AT cornell DOT edu> <20150701104748 DOT GH2918 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20150701104748.GH2918@calimero.vinschen.de>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--x38akuY2VS0PywU3
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jul  1 12:47, Corinna Vinschen wrote:
> On Jun 30 16:13, Ken Brown wrote:
> > On 6/30/2015 3:55 PM, Corinna Vinschen wrote:
> > >On Jun 27 16:52, Corinna Vinschen wrote:
> > >>On Jun 26 18:28, Ken Brown wrote:
> > >>>On the other hand, emacs doesn't really make a full recovery.  For e=
xample,
> > >>>if I try to call a subprocess (e.g., 'C-x d' to list a directory), I=
 get a
> > >>>fork error:
> > >>>
> > >>>Debugger entered--Lisp error: (file-error "Doing vfork" "Resource
> > >>>temporarily unavailable")
> > >> [...]
> > >Just FYI, I don't know yet what happens exactly, but this has nothing
> > >to do with the alternate stack.  The child process fails with a status
> > >code 0xC00000FD, STATUS_STACK_OVERFLOW.  Which is kind of weird, given
> > >that the stack overflow has been averted by calling siglongjmp.
> > >
> > >I have a hunch.  The stack state in the parent is so that TEB::StackLi=
mit
> > >points into the topmost guard area which, when poked into, triggers the
> > >stack overflow exception.  When forking, Cygwin performs exactly this:
> > >It pokes into the stack to push the guard page out of the way, thus
> > >causing the stack memory to be commited, which in turn allows to copy
> > >the stack content from parent to child.
> > >
> > >Ok, I'm not sure if I can debug this soon, but at leats it's not
> > >related to sigaltstack handling nor is it a regression.
> >=20
> > Thanks for the info, that's good to know.  Just out of curiosity, were =
you
> > able to modify your testcase for this, or did you test with emacs?
>=20
> I just added a fork call to my testcase right after the last printf.

My hunch was correct, apparently.  I changed the way the stack info
is set up for the child so only the actually used part of the stack is
prepared for the stack copy in the child.  This not only avoids the
stack overflow in the child, it should shave a few nanoseconds from
the time a fork takes ;)

I uploaded new developer snapshots to https://cygwin.com/snapshots/ and
I'm just building and uploading a new test release.

Please give it another try.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--x38akuY2VS0PywU3
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVk/HdAAoJEPU2Bp2uRE+gU4QP/2qXgLnZyaplc4O44z/bapfJ
HY1+Hb0UlZxBrWWrzf+1LZ5LN6lsvPScA5Z5revx+504+6RNxjfJ7IW7niWNe3eI
ttzP0z7i9etzZC2v00PKiviHvjTZAJShVUMKV6ZvVKJMfPkcAAcshh8L1WXEWiXT
82Mv9qI2zCcDs0fDI4Wg1JYT3UnANKaruqBDEq1HOo1y1bCRXwtiap7cCtiORC21
UnDTnmYczxovlpaDMIMafDjP/UvK2Y7dCaywybbWlU17YDm3F7tn2DNbXDeqoBva
TF5xF/q+5MSNt8F+DahGnm5FS/21C2EnXtARoLLtvDfDaUe2CtnyTppeDCMjRBlW
4w13DUO+FiMZ9iyD0AJBPdYJ7AuUiEhc8y/lsDDrx6Nq/vsCLmo+mbfywHvhHb13
kuuH5oARigeCVQtBdx9vSDtxZFjDBhqewd7AK8vy/W3WZxTZPHygTS6MP2jF+q68
n1HqHoQfNnGEsPUMPtwdykXev+kxhvHeEHQIxCOAtA9FERI7TJoaGn7w3Wd/kxAQ
EhJ8xhiPb4uiwL1zCs2p1fIMoBGFsO8J0Cmi8/apLYmNo9A9D2l40wndUBBYUopp
WBbT42youHF3I6ANbZWK3Z65/zd13/SXykWsyqx0eCERI0qPWEud5xByQiuTotCj
X7BgGLACBT2SV7nVba2A
=AUBn
-----END PGP SIGNATURE-----

--x38akuY2VS0PywU3--

- Raw text -