Mail Archives: cygwin/2009/07/15/14:57:00
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.
cgf
--
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 -