This is either 1. a bug in gdb, or 2. a bug in the documentation, or 3. a feature request. Reading the documentation at http://sourceware.org/gdb/onlinedocs/gdb/Exception-Handling.html I expect to get a KeyboardInterrupt exception whenever I hit C-c. I only get it while python code is directly executed. However, I also expect to get one if I use gdb.execute. def stop_handler(event): print "Stopped: %s" % event gdb.events.stop.connect (stop_handler) try: while True: pass except KeyboardInterrupt: print "Got keyboard interrupt #1" try: gdb.execute ("c") except KeyboardInterrupt: print "Got keyboard interrupt #2" Output: ^CGot keyboard interrupt #1 ^C Program received signal SIGINT, Interrupt.
The second C-c is delivered to the inferior. It is in the foreground due to "c". Then gdb intercepts that SIGINT via ptrace. So I think this is all expected, at least if I understand it properly. Now, the same thing happens if you attach to a program. This case is maybe more arguable.
I think the second C-c should raise a KeyboardInterrupt. At least as long as I don't change how SIGINTs are handled. At the moment it depends on which statement your python script is executing when you hit C-c. You cannot have a single try block and catch C-c. Instead you need a try block and similar code in the stop_handler. I assume a user always expects the same behaviour. Thus, I think it is not optimal that I have to handle C-c at 2 different locations.