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: <4A5E2ED6.3070502@gmail.com>
Date: Wed, 15 Jul 2009 20:32:38 +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: <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>  <4A5E0AB1 DOT 9020201 AT gmail DOT com> <20090715185636 DOT GA16211 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20090715185636.GA16211@ednor.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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:58:25PM +0100, Dave Korn wrote:
>> 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.
> 
> The point is that this is generating the equivalent of a SEGV without
> ever hitting Cygwin's "SEH" code.  Setting a breakpoint on the line
> would likely just show you the call stack but would not provide any
> insight into why the myfault was not invoked.

  Yes.  That's why I said "examine the SEH chain", not "look at the call
stack".  I reckoned that doing so might provide any insight into why the
myfault was not invoked.  For instance, you might see something hooked into
the SEH chain ahead of Cygwin's handler and start to look at what it was and
where it came from; and if not, you would be able to infer that the SEH chain
was not being invoked and start looking at the various SEH security
enhancements in recent windows versions and wondering which one might make it
think it shouldn't call handlers from a non-registered stack-based SEH
registration record.

    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