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
