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/
