www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2009/07/15/12:45:56

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,HK_OBFDOM,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4A5E0AB1.9020201@gmail.com>
Date: Wed, 15 Jul 2009 17:58:25 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
References: <C795A3B019414FFC84425368B30B83F1 AT multiplay DOT co DOT uk> <20090714200631 DOT GP27613 AT calimero DOT vinschen DOT de> <F24D5DF71BEC447DB0E080A0D6451ABB AT multiplay DOT co DOT uk> <20090714205617 DOT GA12534 AT ednor DOT casa DOT cgf DOT cx> <8541BCA91FF64580AA7A8065FBF9C938 AT multiplay DOT co DOT uk> <39B3B148DA514671BB2E1AE46946169C AT multiplay DOT co DOT uk> <20090715000331 DOT GA5635 AT ednor DOT casa DOT cgf DOT cx> <6D01817BC10A4430AFE7A590CC935C09 AT multiplay DOT co DOT uk> <20090715152139 DOT GA694 AT calimero DOT vinschen DOT de> <4A5DFDDF DOT 2000904 AT gmail DOT com> <20090715162243 DOT GL14502 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20090715162243.GL14502@ednor.casa.cgf.cx>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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 thread.cc:verifyable_object_isvalid 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.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019