This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: New call: Please test latest snapshot
On Thu, May 19, 2005 at 10:22:13PM -0400, Christopher Faylor wrote:
>On Fri, May 20, 2005 at 04:17:48AM +0200, Krzysztof Duleba wrote:
>>Christopher Faylor wrote:
>>
>>> >> Program exited normally.
>>> >> (gdb)
>>> >
>>> >Well, that's the funny thing about Cygwin's gdb.
>>>
>>>No, that's the funny thing about debugging in general. There's nothing
>>>special about cygwin's gdb.
>>
>>Really? I'd expect something more like this:
>>
>>(gdb) run Starting program: /home/jsim/k/kd209203/ab
>>
>>Program received signal SIGABRT, Aborted. 0x40142841 in kill () from
>>/lib/libc.so.6
>
>You'd expect gdb to report a SIGABRT when the program exhibits a SIGSEGV
>outside of gdb? That's odd.
>
>My point, since you missed it, is that debugging sometimes changes the
>execution environment enough so that things "work" inside of a debugger
>even though they fail when being debugged. This can happen on cygwin or
>linux or Tru64.
>
>I do have to say, that Windows may be unique in that it enforces
>serialized thread execution on debugged programs so this may either
>mask or cause problems. I don't know if any UNIX platform does that or
>not. If not, I'd have to retract what I said and say that there is
>something special about cygwin (and any other windows debugger) in that
>respect.
Oh, and in the interests of full disclosure, I also have to say that
cygwin's gdb does not understand anything but windows signals. Although
that doesn't have anything to do with what was being reported, I suspect
that this may be where the above confusion is coming from.
This has nothing to do with a program that reports a SIGSEGV only when
not being debugged, though.
cgf
--
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/