pydevd.py is taking 100% CPU in docker

[musikele]

Environment data

• debugpy version: 1.8.5
• OS and version: host: macOS 14.6.1, Macbook M2. Docker image: python:3.8-slim-bookworm, Docker version: v4.34.2
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.20
• Using VS Code or Visual Studio: 1.93.0

Actual behavior

I start my Django docker image with python 3.8 with this command:

python -m debugpy --listen 0.0.0.0:8080 manage.py runserver 0.0.0.0:8888

After starting, these processes take 100% of cpu time:

If you can't read

/usr/local/bin/python /usr/local/lib/python3.8/site-packages/debugpy/_vendored/pydevd/pydevd.py --port 50313 --ppid 1 --client 127.0.0.1 --access-token a8d0020dc0e7cb1780cfec911cb8b8cd5a170796475a13f7d7ca4bfa0368b886 --debug-mode debugpy-dap --preimport /usr/local/lib/python3.8/site-packages;debugpy._vendored.force_pydevd --multiprocess --skip-notify-stdin --json-dap-http --file manage.py runserver 0.0.0.0:8888

Expected behavior

I'd like to debug normally with no process taking 100% of CPUs

Steps to reproduce:

Unfortunately no colleague is getting the same behaviour so I'd like some help to understand if this is my fault or debugpy fault.

I can provide you with logs and everything.

Thanks for the amazing work btw, For some weeks it was working flawlessly, and the issue is happening only on one docker image, not all of them.

[rchiodo]

Is there a reason you're using 3.8? Might work better with 3.11.

[rchiodo]

We'd likely need your source code to reproduce. There's probably something in the source that the debugger is tracing that's taking a really long time.

You might try switching to 3.12 and (our new 3.12 support in 1.8.6) as that should be faster than the old sys.trace implementation we use in 3.8.

[musikele]

hi @rchiodo
Switching to 3.11 is impossible due to many libraries still needing 3.8 to work, but it's a project we're tackling...
I cannot give you the source code due to legal ownership, but here are a couple of things to consider:

1. i tried to reproduce the bug on a blank project and I don't have it.
2. I asked my colleagues (same code, different hosts) to test and they don't see it. I own a Mac with M3 PRO chip.
3. I tried to switch to different versions of the library. from 1.8.2 to 1.8.6 branch, and nothing changed. Shall I try 1.7.x?
4. I mitigated the effect by adding flag --configure-subProcess false:

python -m debugpy --listen 0.0.0.0:8080 --configure-subProcess false manage.py runserver 0.0.0.0:8888

I have no idea what it does but "at least", after a dozen seconds, I can open the page.

So I understand we're stucked and nothing else can be done until I reproduce the bug in a way i can share it. Thanks for the support and I hope you'll soon find out by other means what is happening.

Michele

[rchiodo]

Ah --configure-subProcess false means debugpy won't attempt to attach to child processes. Is your application starting a lot of subprocesses?

Switching to 1.7 won't likely affect anything though.

And yes it would be really hard to determine the root cause without a reproduction. Thanks for the feedback though.