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=gsWkLnhOOPK5Nu7t6jXhvz+E5enVktlBH+Vs7WdOk0ohXt0cYOajF
	4RpHM3mzOgCdDX837qUuJxDQxfSXyfzsCTzOBWOeS4k540ipgiB5HyLSxHk6RviW
	kUoMNsb2gxzxLvDtHGsGgZS3etnNEo69t2xsybRU1+YQdXlNR08zys=
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=UR9g1PLt4z65nU9LP3WuxZHRcyY=; b=QuQmjLK33yFM5kLZnuiO97BuGHXC
	NMPnLVMO5McUFKBV6KVOnxCCNV4H7D/PQoXqqNukzveijlbbrVwsMoeIUxLglIse
	5KUp92tilbQsp+ZJuOnOX9tnEUSkQ0j/H39zaarqEmlucdGF5m/4zMBtPvV+7Qve
	D4QRSuVnXJm2CGU=
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: Fri, 3 Jul 2015 12:47:41 +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: <20150703104741.GZ2918@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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> <20150702121301 DOT GA25423 AT calimero DOT vinschen DOT de> <20150702122047 DOT GS2918 AT calimero DOT vinschen DOT de> <55959036 DOT 8070300 AT cornell DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="xe2geHXJg22At20M"
Content-Disposition: inline
In-Reply-To: <55959036.8070300@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Jul  2 15:25, Ken Brown wrote:
> On 7/2/2015 8:20 AM, Corinna Vinschen wrote:
> >On Jul  2 14:13, Corinna Vinschen wrote:
> >>On Jul  1 22:10, Ken Brown wrote:
> >>>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:
> >>>
> >>>Stack trace:
> >>>Frame        Function    Args
> >>>00100A3E240  00180071CC3 (00000829630, 000008296D0, 00000000000, 00000=
82CE00)
> >>>00030000002  001800732BE (00000000000, 00000000002, 00100A48C80, 00000=
000002)
> >>>00000000000  00000006B40 (00000000002, 00100A48C80, 00000000002, 00100=
A48768)
> >>>00000000000  21000000003 (00000000002, 00100A48C80, 00000000002, 00100=
A48768)
> >>>End of stack trace
> >>>
> >>>$ addr2line 00180071CC3 -e /usr/lib/debug/usr/bin/cygwin1.dbg
> >>>/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exception.h:175
> >>>
> >>>$ 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);
> >
> >Of course this only works "per thread", so if init_sigsegv is called
> >for the main thread, only the main thread gets this treatment.  For
> >testing this should be enough, though.
>=20
> That didn't make any difference.

It should have.  If you don't also tweak STACK_DANGER_ZONE accordingly,
handle_sigsegv should fail to call siglongjmp.  Either way, I tested
it locally as well, and it doesn't work.

In the meantime I found that there's another problem.  Assuming you
longjmp out of handle_sigsegv, the stack will still be "broken".
It doesn't have the usual guard pages anymore, and the next time
you have a stack overflow, NTDLL will simply terminate the process.

I create a wrapper function which resets the stack so it has valid guard
pages again and then the stack overflow can be handled repeatedly.

While I was at it, I found that the setup for pthread stacks is not
quite right, either, so right now I'm hacking on this stuff to make
it behave as expected in the usual cases.

> But I do have a little more information.
> I tried running emacs under gdb with a breakpoint at handle_sigsegv.  The
> breakpoint is hit when I deliberately trigger the stack overflow.  Then I
> continue, emacs says it has recovered from the stack overflow, and I type
> 'C-x d'.  At this point there's a second SIGSEGV and handle_sigsegv is
> called again.  But this time garbage collection is in progress, and
> handle_sigsegv just gives up.

Sounds right to me.

> I don't know what caused the second SIGSEGV but I'll try to figure that o=
ut
> when I next have a chance to look at this.  I also don't know why the sta=
ck
> dump pointed to a crash while setting up the alternate stack, since the
> fatal crash actually seems to have happened later.  But maybe the stack w=
as
> just completely messed up after the second SIGSEGV and the stack dump can=
't
> be trusted.
>=20
> More later.

Thanks!


Corinna

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

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

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

iQIcBAEBCAAGBQJVlmhNAAoJEPU2Bp2uRE+gDCIP/A6Aajv4zyxbJJz1zIeUhkQt
MCtCSPrQp2SbZQPhoc2CYUofcRniGqvnVTHWnEByiyH1Fn6Mbbfc9W6cVwTfvZEo
1yRf8vvw63X9lo6E9luQfpLJ1VG2r9iP4Eiq2fl3dkwe8V766pLYyhNsRPuYfRxf
AUUl5eqLbhKLPAWXb0uoDjYjyn06Kq3hNQFOOZRkVHm3Au5AC9/mDMhtyvPpBi3I
7gW3FavD0aX/bO3UIGe9uvOZia9asma+oOP3bfMnBrWbn3jJKNoLz+f5IyWwNg4b
3NOC9CVVLNhJTyaaDlCrNKSEhdxYadW48TSv4Wf8dmw10ECcZU4P6KzShEUV0Cq/
STc2Q6eKSkhV+H3jrm2w/N5syWaCnz8C5Q96EgEjhn0NXiP84RqXSQtjDoLSPEZ7
MB2j+VZ9vgLYVwAAX/KG3ED1BxhD4H6/ydo3VBYsZylLtdA3rmT9VZUHnUH1Zole
es/6JJRQFBo1zDMirAX18jNKkhiNL9o0tjuoRl0pNCzK0Tt4mxdVuqcRwyXoner7
myDLu5Tj9akJEHaWVYS3omuhmJ72/BCG62kkE0hM4k3+g4UZ5DzJhoIuoce7g3bn
tEySx+ZMgpE9bmTswfBG1icFeK01Zb/tygceMOXu0hllidVXoWRy+o3XPjaE5vY1
yP4l3ZCOdPOJW4hbJjFN
=1WMk
-----END PGP SIGNATURE-----

--xe2geHXJg22At20M--