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 Fri, Jul 17, 2009 at 05:29:20PM +0200, Corinna Vinschen wrote:
>On Jul 17 15:23, Dave Korn wrote:
>> Corinna Vinschen wrote:
>> > 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.
>Sorry, but AFAICS we are not in early startup-and-init.  The threads.dll
>library is a run-time loaded DLL via dlopen due to the
>  use threads;
>statement in the script.  This situation can occur at any point
>during the runtime of an application.

Right, and I don't know how you could make the claim that Cygwin apps
don't install SEH handlers.  We can't possibly know how every Cygwin app
does this.  Obviously there's at least one app out there which has
decided that it needs to use Windows-specific methods to accomplish a
goal.  I'm not exactly thrilled to see code which has decided to dig
deep into Windows internals.  That's what Cygwin is supposed to prevent.


Problem reports:
Unsubscribe info:

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