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 )

Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>> What happens is that this statement
>>>   if ((*object)->magic != magic)
>>> in the function throws an exception
>>> because *object is NULL.  This should be covered by the myfault handler
>>> in this function but for some reason it isn't.
>>  So, set a "*object == 0" conditional breakpoint on that line and see what
>> the SEH chain looks like?
> But the point is that this shouldn't have caused a SEGV.

  Don't understand quite what you're alluding to.  Where did Corinna refer to
a SEGV?  Unless we're using the words differently, a SEGV is a signal, which
is a cygwin posix construct generated in response to an unhandled x86 access
violation exception.  Corinna said that the call to v_o_i caused an
*exception*, as dereferencing a NULL pointer always does, and that it should
have been covered by the myfault handler (which as far as I know works by
wrapping an SEH handler around the block of protected code, and using it to
catch exceptions and longjmp back to the receiver) and which might lead to a
SEGV signal being generated somewhere a long way down the road if it failed to
catch the exception, but I'm just concentrating on the point of failure.
Hence my suggestion to breakpoint it just before the exception happens and see
what the state of the SEH chain looks like.


Problem reports:
Unsubscribe info:

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