[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4

[Ken Brown]

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