Trace KeyboardInterrupt exception?

[Tony Nelson]

I'm trying to find out what is eating some KeyboardInterrupt exceptions
in a fairly large program (yum). My KeyboardInterrupt handler is called
for some Ctl-C presses, but for others nothing seems to happen.
Grepping the source (what of it I've found, looking at import
statements) doesn't turn up anything likely.

My thinking is that either some "except:" clause is eating them, or some
place I haven't looked is eating them, or possibly C code is eating
them. For the first two, at least, I'd like to use a debugger to trace
KeyboardInterrupt exceptions, make sure that they're happening, and see
what is handling them. I don't see a way to trace or break on a
specific exception type in Idle. Can someone give me a hint on how to
do this? I'm willing to consider other debuggers, including gdb (DDD).
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>

 

[andrewdalke]

I'm trying to find out what is eating some KeyboardInterrupt exceptions
in a fairly large program (yum). My KeyboardInterrupt handler is called
for some Ctl-C presses, but for others nothing seems to happen.

... I'd like to use a debugger to trace
KeyboardInterrupt exceptions, make sure that they're happening, and see
what is handling them.

I don't know how to do that in Idle. You can replace the default
Ctrl-C interrupt
handler with your own and use that to inspect the current stack. For
example,
.... print "Keyboard Interrupt!"
.... traceback.print_stack()
.... prev_handler(*args)
........ while 1: pass
....^CKeyboard Interrupt!
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in spin
File "<stdin>", line 3, in new_int_handler
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in spin

There's no real need to call the old handler. You could "raise
KeyboardInterrupt"
or SystemExit or just ignore it, as in
.... global count
.... print messages[count]
.... if count >= len(messages)-1:
.... raise KeyboardInterrupt
.... count += 1
........ 1: "That's ticklish!",
.... 2: "Now, where did that off button go to....",
.... 3: "Do that again and I'll leave.",
.... 4: "Shutdown activated"}.... while 1: pass
....^CTraceback (most recent call last):
File "<stdin>", line 1, in ?
^CSorry, did you want me to do something?
^CThat's ticklish!
^CNow, where did that off button go to....
^CDo that again and I'll leave.
^CShutdown activated
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in spin

Andrew
(e-mail address removed)

 

[Tony Nelson]

I don't know how to do that in Idle. You can replace the default
Ctrl-C interrupt handler with your own and use that to inspect the
current stack.

Thanky you, that helps. Interestingly, some Ctl-Cs don't get caught.
Presumably they're happening in a subprocess.

Now to see if I can get into that situation again where Ctl-C is
ignored. I need to know what's eating the exceptions. I don't think
it's a subprocess in the case I'm concerned with. I don't think yum is
threaded, but apparantly importing the tread module anywhere should keep
KeyboardInterrupt on the main thread anyway (?).

It would be nice if I could inspect the stack and find the exception
handlers. I'm using trace handlers, but their output seems somewhat
spotty and inconsistent, or maybe just confusing.
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>

 

[yairchu]

if you want to interrupt the code to find out where it is,
you can instead connect to it in gdb and get the python traceback of
each thread.
if you're interested I'll post the necesary gdb-macro for that (didn't
put it on the net yet)

 

[Tony Nelson]

if you want to interrupt the code to find out where it is,
you can instead connect to it in gdb and get the python traceback of
each thread.
if you're interested I'll post the necesary gdb-macro for that (didn't
put it on the net yet)

I think I've found the problem, using Python's Bugzilla. This appears
to be unresolved Python bug 926423, unresolved proposed patch 1102879,
don't know if anything ever came of it. See other thread.
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>