Trace KeyboardInterrupt exception?

[Tony Nelson]

I'm trying to find out what is eating some KeyboardInterru pt exceptions
in a fairly large program (yum). My KeyboardInterru pt 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
KeyboardInterru pt 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*nlsn ews@georgea*las tname*.com
' <http://www.georgeanels on.com/>

[andrewdalke@gmail.com]

Re: Trace KeyboardInterru pt exception?

Tony Nelson wrote:[color=blue]
> I'm trying to find out what is eating some KeyboardInterru pt exceptions
> in a fairly large program (yum). My KeyboardInterru pt handler is called
> for some Ctl-C presses, but for others nothing seems to happen.[/color]
[color=blue]
> ... I'd like to use a debugger to trace
> KeyboardInterru pt exceptions, make sure that they're happening, and see
> what is handling them.[/color]

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,
[color=blue][color=green][color=darkred]
>>> import signal
>>> signal.getsigna l(signal.SIGINT )[/color][/color][/color]
<built-in function default_int_han dler>[color=blue][color=green][color=darkred]
>>> prev_handler = signal.getsigna l(signal.SIGINT )
>>> def new_int_handler (*args):[/color][/color][/color]
.... print "Keyboard Interrupt!"
.... traceback.print _stack()
.... prev_handler(*a rgs)
....[color=blue][color=green][color=darkred]
>>> signal.signal(s ignal.SIGINT, new_int_handler )[/color][/color][/color]
<built-in function default_int_han dler>[color=blue][color=green][color=darkred]
>>> def spin():[/color][/color][/color]
.... while 1: pass
....[color=blue][color=green][color=darkred]
>>> import traceback
>>> spin()[/color][/color][/color]
^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
KeyboardInterru pt[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

There's no real need to call the old handler. You could "raise
KeyboardInterru pt"
or SystemExit or just ignore it, as in
[color=blue][color=green][color=darkred]
>>> count = 0
>>> def new_int_handler (signum, frame):[/color][/color][/color]
.... global count
.... print messages[count]
.... if count >= len(messages)-1:
.... raise KeyboardInterru pt
.... count += 1
....[color=blue][color=green][color=darkred]
>>> messages = {0: "Sorry, did you want me to do something?",[/color][/color][/color]
.... 1: "That's ticklish!",
.... 2: "Now, where did that off button go to....",
.... 3: "Do that again and I'll leave.",
.... 4: "Shutdown activated"}[color=blue][color=green][color=darkred]
>>>
>>> def spin():[/color][/color][/color]
.... while 1: pass
....[color=blue][color=green][color=darkred]
>>> spin()[/color][/color][/color]
^CTraceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in spin
KeyboardInterru pt[color=blue][color=green][color=darkred]
>>>
>>> import signal
>>> signal.signal(s ignal.SIGINT, new_int_handler )[/color][/color][/color]
<built-in function default_int_han dler>[color=blue][color=green][color=darkred]
>>>
>>> spin()[/color][/color][/color]
^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
KeyboardInterru pt[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Andrew
dalke@dalkescie ntific.com

[Tony Nelson]

Re: Trace KeyboardInterru pt exception?

In article <1150293702.090 195.324550@y43g 2000cwc.googleg roups.com>,
andrewdalke@gma il.com wrote:
[color=blue]
> Tony Nelson wrote:[color=green]
> > I'm trying to find out what is eating some KeyboardInterru pt exceptions
> > in a fairly large program (yum). My KeyboardInterru pt handler is called
> > for some Ctl-C presses, but for others nothing seems to happen.[/color]
>[color=green]
> > ... I'd like to use a debugger to trace
> > KeyboardInterru pt exceptions, make sure that they're happening, and see
> > what is handling them.[/color]
>
> 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.[/color]

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
KeyboardInterru pt 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*nlsn ews@georgea*las tname*.com
' <http://www.georgeanels on.com/>

[yairchu@gmail.com]

Re: Trace KeyboardInterru pt exception?

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]

Re: Trace KeyboardInterru pt exception?

In article <1150357101.984 761.63310@u72g2 000cwu.googlegr oups.com>,
"yairchu@gmail. com" <yairchu@gmail. com> wrote:
[color=blue]
> 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)[/color]

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*nlsn ews@georgea*las tname*.com
' <http://www.georgeanels on.com/>