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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )

On Jul 17 14:38, Dave Korn wrote:
> Corinna Vinschen wrote:
> > AFAICS, the problem is that _my_tls.el is not the active SEH handler at
> > this point, but it is already part of the chain,
> > _cygtls::init_exception_handler doesn't check for validity and just
> > overwrites the entry in an invalid way.
>   Argh.  Yes, there's no way we can repeatedly enter the same registration
> record into the chain.  I see this has already been anticipated:
> [...]
> > If it's not correct to just skip the OS handlers, we would have to
> > invent a new SEH entry at a lower stack address, rather than reusing
> > the _my_tls entry, which is already in use.
> > 
> > Assuming that skipping the OS handlers is OK, 
>   What if they are try....finally handlers rather than try....except?  Bad
> things might happen?  It might be useful to know what those functions are

If you look again, you see that it's always the same address, always the
same default exception handler in ntdll.dll.  I guess it might be more
correct to add another handler to the chain, rather than to strip the OS
handlers from the chain, but the fact that the OS SEH validity check was
happy with the chain and the testcase worked is kind of relaxing.

> (lookup in windbg?), but then again it might be fragile if we devised a
> solution that relied on that knowledge.  I guess the answer is that if we only
> want a last-chance exception handler we should just make
> _my_tls.init_exception_handler() idempotent so it only installs one handler at
> the start of the chain, but if we want to intercept exceptions ahead of those
> OS handlers (as I think is the intent of the code here) then we need to set up
> and tear down a new SEH record.  The SEH chain has to be a strict stack, with
> entries unlinked in the reverse order to when they're linked; we can't go
> re-ordering it when there are foreign handlers in the mix.

Do we have to take other handlers than the OS handlers and the Cygwin
handlers into account?  Cygwin apps don't install SEH handlers, do
they?  Or do C++ apps?


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

Problem reports:
Unsubscribe info:

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