Using Pdb
by
John Samuel Anderson
—
last modified
Jan 15, 2009 09:33 PM
Finding the bug via the Pdb prompt.
Ready to Rumble
After about 10 minutes, the terminal window drops into the Pdb prompt (remember, we're watching Zope, using instance fg).> /var/plone/infocenters/eggs/ZODB3-3.8.1b7-py2.4-linux-x86_64.egg/ZEO/zrpc/connection.py(700)call() -> raise inst # error raised by server (Pdb)Type l (short for list) to see the location of the current line, in context:
695 if (isinstance(r_args, tuple) and len(r_args) > 1 696 and type(r_args[0]) == exception_type_type 697 and issubclass(r_args[0], Exception)): 698 inst = r_args[1] 699 import pdb; pdb.set_trace(); 700 -> raise inst # error raised by server 701 else: 702 return r_args 703 704 # For testing purposes, it is useful to begin a synchronous call 705 # but not block waiting for its response.(While this is a useful listing, it's much easier to open the file in an editor, since we already know which file it is.) Since the Pdb prompt will also run python statements, let's examine the environment like so:
(Pdb) dir() ['args', 'inst', 'method', 'msgid', 'pdb', 'r_args', 'r_flags', 'self'] (Pdb) method 'pack' (Pdb) args self = method = pack args = (1231182229.8963089, 1) (Pdb) r_args (, ) (Pdb) r_flags 0 (Pdb) self (Pdb) msgid 1861Unfortunately, that's less than useful. It appears that the error occurs in another part of this asynchronous system, and that this is just the message handler. Even a closer look at the code in connection.py indicates that there's some other part of the system responsible for this. Now, where could it be?
Remove the set_trace
Before you move on, don't forget to take the set_trace out, save the file and restart Zope. Otherwise, it will come back and bite you.
Fumbling in the Dark
As you can see, sometimes debugging Plone is not straight-forward. Still, let's keep going, using every idea that comes to mind. If nothing else, you will learn a lot about how Plone works! :)
Visit our