PDB won't stop on breakpoint

Question

I'm quite new with debugging directly with pdb and I am having some issues debugging my Django application. Here is what I'm doing:

python -m pdb manage.py runserver
(pdb) b core/views.py:22
Breakpoint 2 at /Users/raphaelcruzeiro/Documents/Projects/pdb_test/core/views.py:22
(Pdb) c

However the execution passes directly through the breakpoint. Am I missing some command? The manual doesn't elaborate on setting a breakpoint anymore than this.

Answer 1

I was having this issue when creating a Tkinter program that must always be multithreaded, so I could not separate out my threaded code to test. What worked for me is to manually insert breakpoint() into my code before the location I actually want to break. Then, when in the (Pdb) prompt for this breakpoint, create a new breakpoint at the desired location with break linenumber, and continue. I assume this works because the same thread that is creating it will always be the one that hits it.

Example:

> c:\users\me\desktop\folder\file.pyw(2173)Function()
-> while cond == False:
(Pdb) break 2180
Breakpoint 1 at c:\users\me\desktop\folder\file.pyw:2180
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at c:\users\me\desktop\folder\file.pyw:2180
(Pdb) continue
PRINT STATEMENT OUTPUT
> c:\users\me\desktop\folder\file.pyw(2180)Function()
-> while 1:
(Pdb)

Answer 2

I just spent way too long figuring this out, and i thought i'd share it save someone the pain.

It wouldn't break at b [fullfilepath]:[Line number] no matter what i did.

I tried doing b [class].[function] and that didn't work either.

Eventually i put a breakpoint on a python function outside of all the classes and i hit it.

I then did:

import [class]
b [class].[function]

And I hit the breakpoint. In other words the class needs to be imported first before setting the breakpoint else it'll give an error saying it's not found.

Then i remembered that nearly all python code runs in some form of virtual environment, and i had set the breakpoint for the same python code that was laying around but not the running python code in the pip virtual env that was actually being executed by python. For that reason it didn't stop and the breakpoint.

So make sure that if you use a full path, it's the full path as it's seen from inside the virtual environment to the python script that's actually being executed through python and not another file. It only breaks on the exact same python file it's actually parsing.

In other words if you have:

/home/user/test.py

But you're executing python3.10 -m pdb /opt/MyEnv/test.py, then it wont break on line 100 using:

b /home/user/test.py:100

Even though it's the exact same code. This was confusing to me coming from a C/C++ background. It will however break fine on:

b /opt/MyEnv/test.py:100

Also to stop yourself going crazy, start by breaking on something in global scope then import classes and then break on member functions in those classes.

Answer 3

I had my project setup with pyproject.toml config, Removing coverage-related settings for pytest in [tool.pytest.ini_options] section fixed the issue of pdb not working as expected.

[tool.pytest.ini_options]

Removing or commenting out the --cov-* coverage-related options from [tool.pytest.ini_options] sections in pyproject.toml worked for me.

Answer 4

I ran into this issue when writing a neural network in PyTorch. Similar to the accepted answer, the problem was that my DataLoader spun off multiple threads. Removing the num_workers argument allowed me to debug on a single thread.

    train_loader = DataLoader(
        train_dataset,
        batch_size=batch_size,
        num_workers=16, # <-------Remove this argument
        pin_memory=True
    )

If you are running into this issue, a simple fix would be to track down where in your code you are using multiprocessing, and adjust it to run a single thread.

Answer 5

One strange thing I have noticed is that the PDB prompt repeats your previous action when you repeatedly hit enter. Moreover, if you hit enter whilst your program is running, PDB buffers the input and applies it once the prompt appears. In my case, I was running a program using PDB c(ontinue). My program was writing lots of debug info to stdout during initialization, so I hit enter a couple of times to separate the already written output from the output that was going to be written once the breakpoint was triggered. Then, when I triggered the breakpoint via some external action, PDB would stop at the breakpoint but then apply a 'buffered enter' which repeated the c(ontinue) action. Once I stopped hitting enter it all started working normally.

This may sound a bit strange, and I haven't investigated this issue much, but it solved the problem for me. Maybe it helps someone else.

Answer 6

I've been through the same problem.

Try something like python -m pdb ./manage.py runserver --nothreading --noreload 127.0.0.1:8080. It solved the issue for me.

It seems that breakpoints with PDB are thread-specific, and the --nothreading and --noreload options are necessary to avoid some forking that may confuse PDB. This is also why set_trace works, as it's called directly inside the thread of interest.

Answer 7

When I've seen this problem in the past, it's usually because someone has set the breakpoint on a line that is not actually connected to a Python statement that is run. For example, blank lines, comment lines, the wrong part of a multi-line statement.

Answer 8

I usually prefer set_trace() in the source itself, that way the dev server will reload when added/removed, and I don't need to stop and start it again. For example:

def get_item(request):
   import pdb; pdb.set_trace()

When the view is accessed, pdb will kick in.