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=s1hjDq7SSM6vsflzNRAbBOdDSzrL1M1LR+VF9yCkkaOFDEdcaeAjl
	DHhne7IbL8Obz1e49kIBMOCO41v0S5WZhSHYNLRMzqMnjHF0PRxCpdKSsULRFRCk
	neObaJHi/ZuUiEjod1s8jhUDYb4bt6Moq5CC8j2l/Zjy3a9MZ1MSeU=
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=EVKSvh/1BqXCZjbdh0an5JQ3tic=; b=XcvLorPfXy/nbovg3cGffIoBHIkc
	nBdDxr2qVI8cpoQpL3Z3cAqgxf/yXgr/3qQXj7VWmWqghnkL82juVP5SzUEGYX2h
	KuMdN5RSqPHdljBwyrjwaDphw4Ps2SqqqbjWU894IMOzD9N5lnDMxtfarML6nKsE
	TF+EUJmYFrrbt90=
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: Thu, 2 Jul 2015 14:13:01 +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: <20150702121301.GA25423@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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> <20150701135749 DOT GN2918 AT calimero DOT vinschen DOT de> <559449AF DOT 9010804 AT cornell DOT edu> <55949D9A DOT 7060900 AT cornell DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline
In-Reply-To: <55949D9A.7060900@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Jul  1 22:10, Ken Brown wrote:
> On 7/1/2015 4:12 PM, Ken Brown wrote:
> >On 7/1/2015 9:57 AM, Corinna Vinschen wrote:
> >>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=
 example,
> >>>>>>>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 stat=
us
> >>>>>code 0xC00000FD, STATUS_STACK_OVERFLOW.  Which is kind of weird, giv=
en
> >>>>>that the stack overflow has been averted by calling siglongjmp.
> >>>>>
> >>>>>I have a hunch.  The stack state in the parent is so that TEB::Stack=
Limit
> >>>>>points into the topmost guard area which, when poked into, triggers =
the
> >>>>>stack overflow exception.  When forking, Cygwin performs exactly thi=
s:
> >>>>>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.
> >>>>
> >>>>Thanks for the info, that's good to know.  Just out of curiosity, wer=
e you
> >>>>able to modify your testcase for this, or did you test with emacs?
> >>>
> >>>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.
> >
> >That fixes it.  Thanks!
>=20
> I may have spoken too soon.  As I repeat the experiment on a different
> computer, with a build from a slightly different snapshot of the emacs
> trunk, emacs crashes when I type 'C-x d' with the following stack dump:
>=20
> Stack trace:
> Frame        Function    Args
> 00100A3E240  00180071CC3 (00000829630, 000008296D0, 00000000000, 0000082C=
E00)
> 00030000002  001800732BE (00000000000, 00000000002, 00100A48C80, 00000000=
002)
> 00000000000  00000006B40 (00000000002, 00100A48C80, 00000000002, 00100A48=
768)
> 00000000000  21000000003 (00000000002, 00100A48C80, 00000000002, 00100A48=
768)
> End of stack trace
>=20
> $ addr2line 00180071CC3 -e /usr/lib/debug/usr/bin/cygwin1.dbg
> /usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exception.h:175
>=20
> $ addr2line 001800732BE -e /usr/lib/debug/usr/bin/cygwin1.dbg
> /usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exceptions.cc:1639

That points to a crash while setting up the alternate stack.  This is
always a possibility because, in contrast to the kernel signal handler
in a real POSIX system, the Cygwin exception handler is still running on
the stack which triggered the crash up to the point where we call the
signal handler function.  Dependent on how the stack overflow occured,
this additional stack usage may be enough to kill the process for good.

Out of curiosity, can you add this to the init_sigsegv() function:

  #include <windows.h>
  [...]
  init_sigsegv (void)
  {
    [...]
    SetThreadStackGuarantee (65536);
    [...]
  }

And see if that "fixes" the crash?

> The next two days are pretty busy for me, but I'll try to provide further
> information as soon as I have a chance.

Thanks a lot,
Corinna

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

--+HP7ph2BbKc20aGI
Content-Type: application/pgp-signature

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

iQIcBAEBCAAGBQJVlSrNAAoJEPU2Bp2uRE+g7EwP/0FUpqh3Yre7mCtaoafDDiX0
NPdNuLqY4auXqNDtwxiFLT/197klLF1eYIlFpmHdRj/tLBE7K/3gwazK12zgAU2D
Fp6g9BM4JgeLy2WF7JsMkoPEta9pK8kO/5MJrVTyzuYJ1H0T851+vOd7MgqNp+xw
Vf/JAuyYtf2eorJSVpIf9C4XHdL1EUuWna2j/v99ZXhZ65UVjUiKl82NJZydKY8C
N2SgVdLB4FDQdumNjkMnyh3+GRL4/9o/zYPtOfFU7jk7IeoW6o3qj9s2ajHd2TRP
q4c5o7IYsQFzsdXaqEgF/ehE2+mZtTH/PF0h3MJ9MHVlA1SEHSZc5J1d8JfEj+E/
gdR8yctcPMy7bOQ+EKGYVmaAsSmKXsxOAqX1EssXIM5yk9Ozv5tUhofJSEx3we0a
CiVzGNI1wZuCL5dXblcSqbYOQkSpqkHS4DEdY5yBetlA7pt4eRF4wUIZCtHn2ehm
IBv6RJpU4FvsKHqsQ5Z+4QHlYu/UJBtw8UpUnPdychlMDlYzx4yJ/G7GSxY/HbPV
Qe0DFs1HK0Ab1LWIT9VyeqzL3sWqkXPEJgicB7CFkotTYvRx7l4Qr/vqiMU4+bJv
GMNg3MMCjvuu7GtDVnCZuK8qVjwyoxyNGU+2vj/Kl6YGRjY6ubUED7IPi1fC1KzM
CXljdnfJM96gtl7WjVw7
=kOoK
-----END PGP SIGNATURE-----

--+HP7ph2BbKc20aGI--