[Docker] "breakpoint in that file does not exist" error when trying to debug script inside container

[FIying-Scotsman]

Environment data

• debugpy version: 1.8.13
• OS and version: macOS 15.3.1 (identical behaviour on Windows 10 using WSL)
• Python version (& distribution if applicable, e.g. Anaconda): 3.12-alpine
  • Docker Desktop 4.39.0 on macOS; 4.11.0 on Windows (using WSL).
• Using VS Code or Visual Studio: VS Code with the Python plugin.

Actual behavior

Local Docker container running debugpy under localhost waits for VS Code to attach, however breakpoints are never hit - showing "breakpoint in that file does not exist":-

Terminal mirrors Docker logs as expected however breakpoints and variables do not work while the script is running within Docker.

Docker has the correct port exposed (5678 - otherwise the attach wouldn't work as shown above) and remoteRoot path does not seem to change the behaviour. Both '.' and a direct, exact file path within the container to the file being debugged results in the exact same behaviour.

Launch JSON is the default generated template within VS Code, with the "remoteRoot" field changed as appropriate:-

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python Debugger: Remote Attach",
            "type": "debugpy",
            "request": "attach",
            "connect": {
                "host": "localhost",
                "port": 5678
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "." //Have also tried "/opt/opencti-connector/main.py"
                }
            ]
        }
    ]
}

Dockerfile:

# Copy the worker
COPY src /opt/opencti-connector

# Install Python modules
# hadolint ignore=DL3003
RUN apk --no-cache add git build-base libmagic libffi-dev && \
    cd /opt/opencti-connector && \
    pip3 install --no-cache-dir -r requirements.txt && \
    apk del git build-base

# Expose and entrypoint
COPY entrypoint.sh /
RUN chmod +x /entrypoint.sh

WORKDIR /opt/opencti-connector
ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh:-

\#!/bin/sh

# Go to the right directory
cd /opt/opencti-connector

# Launch the worker
python -m debugpy --wait-for-client --listen 0.0.0.0:5678 main.py

This appears to be a similar problem regardless of the code being run in the container as I had also recreated it using the Flask app mentioned in this issue #1491 (direct link to the example Flask project). As per this issue - they had also experienced the 'hollow circle' and breakpoints are not hit.

Expected behavior

Breakpoints should trigger within the container as they do when debugging the same file locally.

Steps to reproduce:

1. Set up example Flask project above.
2. Amend the compose file to include the debug port & debug command
   • command: ["sh", "-c", "pip install debugpy -t /tmp && python /tmp/debugpy --wait-for-client --listen 0.0.0.0:5678 app.py runserver 0.0.0.0:5000 --nothreading --noreload"]
3. Run docker compose build
   • docker compose -f "docker-compose.debug.yml" up -d --build .
4. Amend the "remoteRoot" field as required.
5. Set a breakpoint in the app.py and remote-attach the debugger.
6. Breakpoints are now marked as "does not exist" despite the file existing in the container using the exact file path.

[rchiodo]

If you set this variable in the remote environment:

DEBUG_PYDEVD_PATHS_TRANSLATION=True

And then launch debugpy with logging:

python -m debugpy --wait-for-client --log-to <some directory> --listen 0.0.0.0:5678 main.py

That should generate a debugpy.pydevd.<pid>.log file that will list out where debugpy looked for the file with the breakpoint in it.

[FIying-Scotsman]

If you set this variable in the remote environment:

DEBUG_PYDEVD_PATHS_TRANSLATION=True

And then launch debugpy with logging:

python -m debugpy --wait-for-client --log-to <some directory> --listen 0.0.0.0:5678 main.py

That should generate a debugpy.pydevd.<pid>.log file that will list out where debugpy looked for the file with the breakpoint in it.

Ah fantastic - thanks for the info. I'll give this a go and see where I get.

[FIying-Scotsman]

Thanks for the tip- I've generated a couple of logs which helped narrow down the localRoot path was wrong. It was reading the parent project folder, not the subfolder with the code I actually wanted to debug:-

             Client[1] <-- {
                 "seq": 33,
                 "type": "response",
                 "request_seq": 14,
                 "success": true,
                 "command": "setBreakpoints",
                 "body": {
                     "breakpoints": [
                         {
                             "verified": false,
                             "message": "Breakpoint in file that does not exist.",
                             "source": {
                                 "name": "app.py",
                                 "path": "/Users/developer/Documents/Development/flask_docker-master/app/app.py"
                             },
                             "line": 29
                         }
                     ]
                 }
             }

Setting the localRoot to the path above worked as expected and breakpoints were hit.

Went through the VS Code variables and found the below one which works without needing to hard-set the path like above:-

"pathMappings": [
                {
                    "localRoot": "${fileDirname}",
                    "remoteRoot": "."
                }
            ]

Can now debug scripts within containers as expected. Many thanks for the tip! Closing as the issue was solved, and hopefully others having the same issue have something to work with.