This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Mysterious random crashes with latest snapshots


----Original Message----
>From: Christopher Faylor
>Sent: 30 June 2005 17:58

> On Thu, Jun 30, 2005 at 05:45:52PM +0100, Dave Korn wrote:
>> ----Original Message----
>>> From: Christopher Faylor
>>> Sent: 30 June 2005 15:58
>>> On Thu, Jun 30, 2005 at 03:37:25PM +0100, Dave Korn wrote:
>>>> I think I remember noticing that backtracing across sigfe doesn't
>>>> always work too well.  Then again, there could be a problem with the
>>>> debug info:
>>> 
>>> "doesn't always" == "never".
>>> 
>>>>> #3 0x00435d27 in fhandler_pipe::get_guard ()
>>>> 
>>>> makes no sense.  But I would imagine the peculiarity is down to sigfe;
>>>> it does something unexpected to the stack frame, that the debug info
>>>> doesn't reflect.
>>> 
>>> No, it's due to the fact that 0x00435d27 is an address in the
>>> application and the application has no debugging symbols.
>> 
>> That doesn't explain how it managed to think that 0x0040xxxx was
>> somewhere in the middle of the dll.
> 
> Nor does the existence of sigfe in a stack chain cause gdb to change the
> way an address is turned into a symbol.

  I don't think that was what I was saying... I think I was saying that the
debug info could be incorrect, regardless of any complications caused by
sigfe.  *Because* I was expecting gdb's way of turning an address to a
symbol to *not* be affected by sigfe, I found it odd that it settled on a
larger-valued signal.  I would find this odd regardless of the state of the
stack, because the state of the stack should not affect gdb's (actually
bfd's, to be pedantic) method of converting an address to a symbol.

> fhandler_pipe::get_guard is a strange symbol that gdb is incorrectly
> choosing for the name of a function, possibly because it has the sign
> bit set and there's some inappropriate signed comparison somewhere in
> gdb's symbol handling code.

  It's a pretty ordinary inlined function, and at least in my
(first-random-build-to-hand-of-the) dll, there are functions at
just-slightly-larger and just-slightly-smaller addresses, so I really can't
see why any lookup would settle on the one in the middle rather than the
later or earlier one!

610e1cc0 t .text$_ZNK13fhandler_base9get_guardEv
610e1cd0 t .text$_ZNK13fhandler_pipe9get_guardEv
610e1ce0 t .text$_ZNK15fhandler_socket17need_fixup_beforeEv

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]