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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=CD3PiO1dh1YHP6IduVy0csScStJ0RkGWH9d96FoZSQZ
	vYCcIjKxNGfp2Ikko5k7dK9/wN86Watr+Afo+mRoQdp6ZQzXTI3gJtoDpBQEsXpn
	flDT58mJVnkOYaZTKtAzIAGnAA+DsCoX2Q7gG+xOyaZWRBRXc13jWakvDbkqObas
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=pzgnrgYsSeis4JHS6y1BzPBahcc=; b=Ps9Jb9WSvFBCCUcFn
	oJc+qDlIK+liwcKZkJMBn8zIcaVKyU7U8K0mTMQFw32HW+knt9v+k3RnjeOlhrJJ
	YyA9SLdaOcAAqo0DPq1JruCRGgCKFJ4JceZ8svOjxytTjtHt/9LbKLzl/fvaHDon
	XwRtiP4NYnywLQMTS+WRNWM6F0=
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=-1.0 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	limerock04.mail.cornell.edu
X-CornellRouted:	This message has been Routed already.
Message-ID:	<559C14D2.1000303@cornell.edu>
Date:	Tue, 07 Jul 2015 14:05:06 -0400
From:	Ken Brown <kbrown AT cornell DOT edu>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4
References:	<announce DOT 20150705213417 DOT GH2918 AT calimero DOT vinschen DOT de> <5599E4C5 DOT 1010109 AT cornell DOT edu> <20150706100158 DOT GJ2918 AT calimero DOT vinschen DOT de> <559A7F74 DOT 1000402 AT cornell DOT edu> <20150706144555 DOT GR2918 AT calimero DOT vinschen DOT de> <559AA4C8 DOT 30309 AT cornell DOT edu> <20150706163424 DOT GV2918 AT calimero DOT vinschen DOT de> <20150707154916 DOT GB2918 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20150707154916.GB2918@calimero.vinschen.de>
X-IsSubscribed:	yes

On 7/7/2015 11:49 AM, Corinna Vinschen wrote:
> On Jul  6 18:34, Corinna Vinschen wrote:
>> On Jul  6 11:54, Ken Brown wrote:
>>> On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
>>>> If you want to know how big your current stack *actually* is, you can
>>>> utilize pthread_getattr_np on Linux and Cygwin, like this:
>>>>
>>>> #include <pthread.h>
>>>>
>>>>    static void
>>>>    handle_sigsegv (int sig, siginfo_t *siginfo, void *arg)
>>>>    {
>>>>      pthread_attr_t attr;
>>>>      size_t stacksize;
>>>>
>>>>      if (!pthread_getattr_np (pthread_self (), &attr)
>>>> 	&& !pthread_attr_getstacksize (&attr, &stacksize))
>>>>        {
>>>> 	beg = stack_bottom;
>>>> 	end = stack_bottom + stack_direction * stacksize;
>>>>
>>>> 	[...]
>>>>
>>>> Unfortunately this is non-portable as well, as the trailing _np denotes,
>>>> but at least there *is* a reliable method on Linux and Cygwin...
>>>
>>> Thanks.  That fixes the problem too, even with the call to setrlimit left
>>> in. I'll report this to the emacs developers.
>>
>> Excellent, thanks for testing this!
>
> Uh oh.  We have a problem there.  This only worked accidentally, at least
> on x86_64.  What happens is that pthread_getattr_np checks the validity
> of the "attr" parameter and while doing so it may (validly) raise a SEGV.

Yes, I discovered that too.  I was just about to send off an emacs bug 
report and patch, but then I decided to test it once more and got the SEGV.

> Usually this SEGV is catched by a special SEH handler in Cygwin, which
> is used to implement __try/__except blocks in Cygwin.  The validity
> check returns the matching information "object uninitialized" to the
> caller.
>
> Not so here.  Since we're still in exception handling while running the
> signal handler, another nested SEGV makes the OS kill the process without
> calling any SEH exception handler on the way.
>
> The problem is, there doesn't seem to be an elegant way around that on
> x86_64.  From the application perspective you can just initialize the
> pthread_attr_t to 0, as in
>
>    pthread_attr_t attr = { 0 };
>
> but that's ... unusual.  It's so unusual that nobody will ever think of
> it.  The other way to "fix" this in the application itself is to call
> pthread_getattr_np in the main() function, which works because we're not
> running in the context of the exception handler.
>
> The only solution inside Cygwin I found so far is this:
>
>    Every myfault setup will have to capture the current thread context
>    and set up a vectored continuation handler.  This handler will be
>    called if no other exception handler feels responsible for an
>    exception.  Fortunately it's called even while another exception is
>    still handled.  The vectored handler then restores the thread context,
>    just with tweaked instruction pointer.
>
> What bugs me with this solution is not only that it looks rather
> hackish, but also that it comes with a performance hit.  The fact
> that every __try/__except block has to call RtlCaptureContext is
> not exactly free of charge...
>
> As you might have noticed, this has nothing to do with the alternate
> stack.  It's just YA problem which cropped up during this testphase.

Yep.  But the good news is that the alternate stack is working.

Ken

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