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