GDB Ctrl-C Interrupt Fails WORKAROUND
Thu Jun 15 09:53:00 GMT 2006
On Thu, Jun 15, 2006 at 01:20:40AM -0700, Kyle McKay wrote:
> I'm almost never running gdb from a genuine DOS command prompt.
> Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't
> work in those.
> Finally, it NEVER works no matter what if you are debugging a program
> built with a different compiler such as m$ visual C++. And, of
> course, you say I have no reason to do that since the debugging
> symbols will not be compatible. However, the m$ visual C++ built
> program is then loading a cygwin/mingw built DLL. CTRL-C doesn't
> work in this case to interrupt the running program. Although if you
> are careful you can get breakpoints set, but if you change your mind
> after you start running the program again then you're out of luck.
> That's where the debugbreak utility comes in very handy.
> Lacking the ability to interrupt a running program severely limits
> gdb's usefulness. Fortunately there's a workaround available.
I find it does it to me 100% of the time if I'm using putty+ssh or
putty+cygputty hack. There's no way I'm using the native cmd shell or
the default cygwin cmd shell. It's extremely frustrating when one realizes
they've just done a "d b", "c" and realize they have no ability to now
stop gdb or even stop anything without hitting up task manager and killing
BTW Kyle, you can extend your program greatly by using process enumeration
coupled with strcmp on the image name to find the pid based on a string and
automatically signal it. But honestly I don't think this program should be
needed in the first place.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin