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:
> On Jul 17 14:38, Dave Korn wrote:
>> Corinna Vinschen wrote:

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

  I'm surprised.  Whatever it was (presumably the part of the OS dynamic
loader that is responsible for invoking DllMain) that put those two OS
handlers at the front of the chain before we arrived in _cygwin_dll_entry@12()
is liable to try and unlink them after we return, isn't it?  Perhaps it has a
bit of robustness code so it doesn't unlink them if the head pointer doesn't
match what it's expecting.  Hmm.

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

  Nope, they don't, but that will probably not be the case forever, there are
(long-term) moves afoot to get SEH support into the compiler.  However, we're
in early startup-and-init here; we don't need to worry about what the
application will do once it finally gets going.


Problem reports:
Unsubscribe info:

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