BdbQuit raised when debugging Python with pdb

Question

Recently when adding the pdb debugger to my Python 2.7.10 code, I get this message:

Traceback (most recent call last):
  File "/Users/isaach         


        

Answer 1

One possible reason is that you are running the Python script in the background. When a process runs in the background, you can't send input to the process via terminal and hence pdb console can't work. Eventually, it raises bdbquit.

Answer 2

Apart from Eirik Fuller answer I would like to add that you can't be using pdb in something thats running in a different process. For debugging you can check this answer: https://stackoverflow.com/a/23654936/7806805 but it seems very hackish or you can make your program run in a single thread. Consult the documentation: https://docs.python.org/3/library/concurrent.futures.html. For multiprocessing issues you might even want to go through https://www.reddit.com/r/learnpython/comments/46x9sm/why_is_pdbset_trace_crashing_whenever_it_is_in_an/

Anyways your question lacks much needed context. Please add on to your question.

Answer 3

For those of you running into this with Django tests, it can be caused by passing the --parallel flag to the test command. This is due to multiprocessing, as pointed out in previous replies. Try removing that flag to see if it solves the problem, it did for me.

Answer 4

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.

Answer 5

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 continue 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.