Question

there.
I have some code written for Python 3.1 that is misbehaving. If it was some C code, I’d just use gdbserverfirst, attach to the process (it’s involved in a fairly sophisticated command line, where the python process receives its input on stdin), fire my favourite GDB front-end and I’ll be ready to figure out why it’s going wrong.

But it’s python. I just tried the pdb module, but I can’t interrupt the process when it goes off: I get a “KeyboardInterrupt” instead (and I need to change the rest of the command chain so that they give set_ptrace a go)

I tried winpdb, which produced curious error message

   Unhandled Exception (in pyshared/rpdb2.py)

and asked for a “password” before I could attach to the process. It gives me the overall feeling that winpdb is for python2 only.

I just tried gdb __main__.py in order to attach to the running process, but that says “format not recognized”, as one could imagine.

Where is the manpage I’ve missed ?

PS: oh, it’s a multi-threaded process, if that matters.

A minimal example:

import pdb

pdb.set_trace()  # press 'c' here to continue
while(True):
    print("hi")  # hit CTRL+C here ... will just kill the program with python 3.1

print("ooh")

Answer 1

The typical way of using pdb is to put a line with:

import pdb;pdb.set_trace()

Where you want the break. If you want the break to be conditional, then you just add the condition, like:

if x > 1000:
    import pdb;pdb.set_trace()

No CTRL-C is involved.

However, a CTRL-C hook will be installed if you let the pdb module run the script:

python3 /path/to/stdlib/pdb.py myscript.py

A shorter and simpler way to write that is:

python3 -m pdb myscript.py

Some linux distributions will also make a link to pdb.py in /usr/bin, meaning you get it as a command:

pdb3 myscript.py

All these three commands above do the same thing. That thing is however different from the pdb.set_trace(), as pressing CTRL-C will then enter post-mortem debugging. That means you can’t step through the code as the next step would be exiting the program. It is therefore much less useful than the above technique. It can however be a quick way to figure out what in your code is taking a lot of time, when it is running slow, and it will then allow you to put in a set_trace() in the correct place to figure out why it is slow.

It does also indeed as you indicate above, seem to be broken in Python 3.1. It does however work in Python 3.2.

It will only work in simple cases, though, in more complex cases you need to use profiling to find the culprit.