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

How do you run your process? My guess is that your process is not attached to a terminal or something like that. Is this a subprocess or something like that? — shx2, Jan 21 '16 at 20:50
@shx2, subprocess? Could somehow the use of [Luigi](https://pypi.python.org/pypi/luigi) cause this? — toto_tico, Jul 20 '17 at 07:41
I encountered [the same issue](https://stackoverflow.com/questions/51453619/pdb-crashed-cannot-set-breakpoint). Really hope it could be resolved — Daming Lu, Jul 23 '18 at 16:28

teewuane · Answer 1 · 2018-03-19T17:22:31.543

26

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.

edited Mar 19 '18 at 17:22

answered Feb 10 '18 at 10:46

teewuane

5,524
5
37
43

2

Updated my answer to whoever down voted. If you down voted, please do re read answer and leave an explanation as to why this is not answering the question. – teewuane Mar 19 '18 at 17:23
How exactly did you do it then? – Abhishek Rai Jul 12 '21 at 08:09
@AbhishekRai Are you trying to run PDB in production? I think what you need to do is not run that in production and remove the pdf.set_trace() from your code. – teewuane Jul 14 '21 at 19:44
still don't understand..how to debug it then? – Abhishek Rai Jul 16 '21 at 18:46

Eirik Fuller · Answer 2 · 2017-06-14T14:29:17.747

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.

it would be great if you could specify possible causes of BdbQuit as pdb doesn't raise it in some scripts. — Alex, Jun 05 '17 at 16:39
this is not the complete answer, there are many other limitations of `pdb` like it cannot work in a multiprocess pool and so on. You fail to mention those. — Ishan Srivastava, Mar 07 '18 at 03:33
Running with `python -m pdb` (even in python 3.7) still hits this issue. — Noein, Jul 14 '21 at 16:51
Thanks for this answer! This is actually what is most likely going wrong for 99% of people coming here. In my case, I was piping input to a Python process over STDIN. This causes the EOF to be immediately read by the `pdb` debugger, hence an immediate `BadQuit`. — Malcolm, Mar 02 '22 at 00:36

score 17 · Answer 3 · edited Oct 25 '21 at 09:37

17

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.

edited Oct 25 '21 at 09:37

mkrieger1

19,194
5
54
65

answered Jan 29 '19 at 11:31

Siva Prakash

4,626
34
26

score 6 · Answer 4 · answered Mar 07 '18 at 03:36

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.

score 3 · Answer 5 · answered Nov 26 '21 at 12:49

3

you can use comand docker-compose run --rm --service-ports {YOUR_CONTAINER} after added:

def your_f():
    **import pdb
    pdb.set_trace()**
    result = your_logic
    return result

exmaple:

answered Nov 26 '21 at 12:49

Артемий Шувалов

71
2

Thanks! But instead of container name I used compose service name and without `--service-ports`. – ruslan_krivoshein Dec 24 '21 at 17:24

score 1 · Answer 6 · answered Aug 20 '20 at 07:43

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.

score 1 · Answer 7 · answered Jul 27 '22 at 18:57

I encountered this issue when piping data into my script. It seems pdb doesn't want to hold the pipe open so it throws BdbQuit. I fixed the issue by saving my stdin data into a temp file and then reading the temp file from python.

Before

$ pbpaste | script.py
Traceback (most recent call last):
  File "/Users/admin/Code/script.py", line 78, in <module>
    process(args)
  ... blah blah ...
  File "/usr/local/Cellar/python@3.9/3.9.13_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "/usr/local/Cellar/python@3.9/3.9.13_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/bdb.py", line 113, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit

After

$ pbpaste > temp.txt
$ python3 script.py test.txt 
> /Users/admin/Code/script.py(49)f()
-> hello = "world"
(Pdb)

score 1 · Answer 8 · answered Nov 12 '22 at 01:04

We need to enable shell input for the docker service that runs Django. If you're using docker compose, add: stdin_open: true in your docker-compose file:

version: '3'

services:
  ...
  django_app:
    build: .
    ports:
      - '8000:8000'
    stdin_open: true

score 0 · Answer 9 · answered Sep 24 '21 at 19:37

I've had more luck using pdbpp, which is a drop in replacement for pdb, i.e. in doesn't require anything else than being itself (no plugin, no extra configuration/options). It supports autocompletion, which is what I was after with ipdb.

You can install it with pip install pdbpp.

score 0 · Answer 10 · answered Oct 11 '22 at 15:56

0

I encountered this error when there was a breakpoint() call left in my code. It is pretty similar to other causes raised here (various uses of pdb). Just know that this is also a possibility.

answered Oct 11 '22 at 15:56

noamgot

3,962
4
24
44

BdbQuit raised when debugging Python with pdb

10 Answers10

Linked