BdbQuit raised when debugging Python with pdb
Recently when adding the pdb
debugger to my Python 2.7.10 code, I get this message:
Traceback (most recent call last):
File "/Users/isaachess/Programming/vivint/Platform/MessageProcessing/vivint_cloud/queues/connectors/amqplib_connector.py", line 191, in acking_callback
callback(message.body)
File "/Users/isaachess/Programming/vivint/Platform/MessageProcessing/vivint_cloud/queues/consumable_message_queue.py", line 32, in deserialized_callback
self._callback_method(msg)
File "/Users/isaachess/Programming/vivint/Platform/BusinessLogic/businesslogic/util/statsd_util.py", line 95, in _time_func
retVal = f(*args, **kwargs)
File "/Users/isaachess/Programming/vivint/Platform/MessageProcessing/vivint_cloud/net/router.py", line 226, in handle
try:
File "/Users/isaachess/Programming/vivint/Platform/MessageProcessing/vivint_cloud/net/router.py", line 226, in handle
try:
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/bdb.py", line 49, in trace_dispatch
return self.dispatch_line(frame)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/bdb.py", line 68, in dispatch_line
if self.quitting: raise BdbQuit
BdbQuit
This is after inserting the line:
import pdb; pdb.set_trace()
in the code.
I cannot figure out why this is happening. I've read up on Bdb and Bdbquit, but cannot figure out why this is happening in my code. Can anyone provide me with some hints of why this happens in general? I really want to get the debugger working again.
I ran into this when I left import pdb
and a pdb.set_trace()
in my production code. When the pdb.set_trace()
line was executed, python was waiting for my input to tell it to c
ontinue or step into, etc... Because the python code was being called by a web server I wasn't there to press c
to continue. After so long (not sure how long) it finally raised the BdbQuit
exception.
I didn't have anything setup to catch that exception so it raised a 500 in my web server.
It took me a while to understand that my debug code running in an a daemon/background was causing the issue. I felt silly.
If you continue from the (pdb)
prompt and allow your code to finish normally, I wouldn't expect output like the traceback you indicated, but if you quit pdb
, with the quit
command or ^D (EOF), a traceback like that occurs because there is nothing to catch the BdbQuit
exception raised when the debugger quits. In bdb.py
self.quitting
gets set to True
by the set_quit
method (and by finally
clauses in the various run methods). Dispatch methods called by trace_dispatch
raise BdbQuit
when self.quitting
is True
, and the typical except:
clause for BdbQuit
is a simple pass
statement; pdb
inherits all of that from gdb
.
In short, exception handling is used to disable the system trace function used by the debugger, when the debugger interaction finishes early.
One way to avoid that traceback altogether is to use pdb
differently. Rather than calling pdb.set_trace()
from your code (and not handling BdbQuit
at all), you can invoke your code within pdb
(rather than vice versa), at which point the BdbQuit
exception will be handled as intended by pdb. That will also allow you to choose breakpoint locations without modifying your code (using pdb
's break
command). Or you can mix the two approaches; run your code under pdb
, pdb.set_trace()
calls and all, and those calls will be breakpoints that you can remove only by modifying your code.
You can invoke your code within pdb
by using the pdb
command with your script invocation as its command line arguments, or with python -m pdb
.