This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


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

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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]