469,612 Members | 1,948 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,612 developers. It's quick & easy.

Trace KeyboardInterrupt exception?

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/>
Jun 13 '06 #1
4 2566
Tony Nelson wrote:
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,
import signal
signal.getsignal(signal.SIGINT) <built-in function default_int_handler> prev_handler = signal.getsignal(signal.SIGINT)
def new_int_handler(*args): .... print "Keyboard Interrupt!"
.... traceback.print_stack()
.... prev_handler(*args)
.... signal.signal(signal.SIGINT, new_int_handler) <built-in function default_int_handler> def spin(): .... while 1: pass
.... import traceback
spin() ^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
File "<stdin>", line 4, in new_int_handler
KeyboardInterrupt
There's no real need to call the old handler. You could "raise
KeyboardInterrupt"
or SystemExit or just ignore it, as in
count = 0
def new_int_handler(signum, frame): .... global count
.... print messages[count]
.... if count >= len(messages)-1:
.... raise KeyboardInterrupt
.... count += 1
.... messages = {0: "Sorry, did you want me to do something?", .... 1: "That's ticklish!",
.... 2: "Now, where did that off button go to....",
.... 3: "Do that again and I'll leave.",
.... 4: "Shutdown activated"}
def spin(): .... while 1: pass
.... spin() ^CTraceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in spin
KeyboardInterrupt
import signal
signal.signal(signal.SIGINT, new_int_handler) <built-in function default_int_handler>
spin() ^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
File "<stdin>", line 5, in new_int_handler
KeyboardInterrupt


Andrew
da***@dalkescientific.com

Jun 14 '06 #2
In article <11**********************@y43g2000cwc.googlegroups .com>,
an*********@gmail.com wrote:
Tony Nelson wrote:
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.


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/>
Jun 14 '06 #3
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)

Jun 15 '06 #4
In article <11*********************@u72g2000cwu.googlegroups. com>,
"ya*****@gmail.com" <ya*****@gmail.com> wrote:
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/>
Jun 15 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Steve Holden | last post: by
8 posts views Thread by Ivan Nestlerode | last post: by
reply views Thread by PantherSE | last post: by
7 posts views Thread by Andy Fish | last post: by
1 post views Thread by darren kirby | last post: by
reply views Thread by Fredrik Tolf | last post: by
2 posts views Thread by Michael Goerz | last post: by
7 posts views Thread by Brendon Costa | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.