Bug 14674

Summary:	No KeyboardInterrupt exception during gdb.execute
Product:	gdb	Reporter:	Marc Brünink <m>
Component:	python	Assignee:	Not yet assigned to anyone <unassigned>
Status:	NEW ---
Severity:	minor	CC:	tromey
Priority:	P2
Version:	HEAD
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Marc Brünink 2012-10-05 01:35:19 UTC

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.

Comment 1 Tom Tromey 2013-01-21 14:43:30 UTC

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.

Comment 2 Marc Brünink 2013-01-22 09:39:04 UTC

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.