[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4

Tue Jul 7 18:05:00 GMT 2015

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