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 )

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:

  /* Windows apparently installs a bunch of exception handlers prior to
     this function getting called and one of them may trip before cygwin
     gets to it.  So, install our own exception handler only.
     FIXME: It is possible that we may have to save state of the
     previous exception handler chain and restore it, if problems
     are noted. */

  Time to fix the fixme, I guess.

> 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
(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.


Problem reports:
Unsubscribe info:

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