Mail Archives: cygwin/2009/07/15/15:20:00
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
- Raw text -