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]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4


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.

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.


Oh well,
Corinna

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

Attachment: pgpO9sD9i8uag.pgp
Description: PGP signature


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