debugpy maps properly the path for setting breakpoints, but not for module location (and thus cannot open the file using the call stack while debugging)

[yajo]

Environment data

• debugpy version: 1.2.0
• OS and version: Debian GNU/Linux 9.13 (stretch)
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.5.10
• Using VS Code or Visual Studio: VS Code

This is my launch configuration (there are several; the one that affects this issue is called "Attach Python debugger to running container"). You can see that it has lots of path mappings because this is a complex multi-root project.

Actual behavior

Full debug session logs. Relevant parts:

1. Debugpy acknowledged the proper path mapping for the l10n_es_toponyms module.
2. The breakpoint seems to be properly enabled.
3. Debugpy seems to be mapping incorrectly the odoo.addons.l10n_es_toponyms.tests.test_l10n_es_toponyms module into /var/home/yajo/prodevel/doodba-devel-12.0/odoo/custom/src/odoo/addons/l10n_es_toponyms/tests/test_l10n_es_toponyms.py instead of /var/home/yajo/prodevel/doodba-devel-12.0/odoo/custom/src/l10n-spain/l10n_es_toponyms/tests/test_l10n_es_toponyms.py

Expected behavior

When clicking on the stack trace, or just when the python code is being paused by the debugger, inside the l10n-spain/l10n_es_toponyms/tests/test_l10n_es_toponyms.py:10 breakpoint, VSCode should properly open the file.

Steps to reproduce:

Well, as you might have guessed this is not going to be "minimal", but well... this is so hard to trigger that this is what it takes 🤷:

First, you are expected to have these tools to be able to reproduce it:

1. Linux.
2. Python 3.
3. Git.
4. Docker running in localhost.
5. Your user with write permissions to the docker socket (usually do sudo usermod -aG docker $USER).
6. Some python CLI apps that you'll need to make it work: pip install pre-commit invoke docker-compose

git clone -b 12.0 https://github.com/Yajo/doodba-devel.git doodba-devel-12.0
cd doodba-devel-12.0
invoke develop
invoke img-pull img-build --pull git-aggregate resetdb -m l10n_es_toponyms
code doodba.doodba-devel-12.0.code-workspace

Now that you opened the workspace in VSCode, and have all the code available:

1. Open l10n-spain/l10n_es_toponyms/tests/test_l10n_es_toponyms.py file.
2. Set a breakpoint on line 10.
3. While that file is still focused, go to debug tab.
4. Select "Test and debug current module" execution option.
5. Wait until the debugger hits line 10.

cc @joao-p-marques

[fabioz]

The logs aren't complete, so, I can't really diagnose this properly.

In particular, I'm interested in the pydevd log file. Can you provide it?

On a first glance I think that in this case one of the paths has more than one translation back and we just go with the first one found (the pydevd log should have more info on the actual targets and translations to be able to diagnose this better).

Ideally your mapping should be an injective function, but if that's not possible, you should put the ones you want to match first earlier in that list.

p.s.: please attach the log files to this issue instead of putting it in a gist.

[yajo]

El vie, 27 de nov de 2020 a las 05:22, Fabio Zadrozny <notifications@github.com> escribió:

In particular, I'm interested in the pydevd log file. Can you provide it?

How can I get those logs? Do they come from the container running debugpy, or from the dev machine running vscode?

[fabioz]

It should be generated in the server (where debugpy is running).

You should be able to set the DEBUGPY_LOG_DIR environment variable to a directory where the logs will be generated in this case.

[yajo]

OK, thanks. Here are the logs:

debugpy.adapter-39.log
debugpy.pydevd.1.log
debugpy.server-1.log

Searching for l10n_es_toponyms I see that the first appearance of a wrongly mapped path is in line 6432 of debugpy.pydevd.1.log, which says:

sending cmd (http_json) -->     CMD_MODULE_EVENT {"body": {"reason": "new", "module": {"path": "/var/home/yajo/prodevel/doodba-devel-12.0/odoo/custom/src/odoo/addons/l10n_es_toponyms/tests/test_l10n_es_toponyms.py", "name": "odoo.addons.l10n_es_toponyms.tests.test_l10n_es_toponyms", "id": 0, "package": "odoo.addons.l10n_es_toponyms.tests"}}, "event": "module", "seq": 104, "type": "event", "pydevd_cmd_id": 203}

[yajo]

Were those logs helpful? Anything else I can do?

[fabioz]

I just took a look and I forgot to ask you to turn on the debugging of the actual translation.

Can you rerun that setting the environment variable below and provide the new logs?

DEBUG_PYDEVD_PATHS_TRANSLATION=1

[fabioz]

Actually, I've been able to setup a test where I can reproduce this.

This is happening because the last / is actually removed during the path translation, so, it's matching: /opt/odoo/auto/addons/l10n_es.

I'll take a look into fixing that.

As a workaround you can put the mapping:

{
"localRoot": "/var/home/yajo/prodevel/doodba-devel-12.0/odoo/custom/src/odoo/addons/l10n_es/",
"remoteRoot": "/opt/odoo/auto/addons/l10n_es/"
},

as the last mapping so that it has less priority.

[yajo]

I just tested installing debugpy from git master in the container, and the bug is fixed. Thank you! ❤️