Debugger with gevent doesn't hit breakpoints

[InceptionOfCode]

Environment data

• debugpy version: 1.6.5 (default from VS Code Python Extension 2022.20.2)
• OS and version: Linux Mint 21.1
• Python version : 3.8 (venv)
• VS Code version: 1.74.3
• gevent version: 20.9.0
• greenlet version: 0.4.17

Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534
Date: 2023-01-09T16:57:40.428Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Linux x64 5.15.0-58-generic
Sandboxed: No

Actual behavior

When Gevent support is enabled the debugger doesn't hit the breakpoints. Without Gevent and the framework (Odoo) default threaded mode debugger works fine.

Expected behavior

Debugger should hit the breakpoints.

Steps to reproduce:

1. Setup an Odoo environment
2. Run it with a worker count > 0
3. Launch it with VS Code (gevent enabled)

[InceptionOfCode]

Actually running the web app without the gevent support from VS Code logs the following warning but the debugger works as expected.

It seems that the gevent monkey-patching is being used.
Please set an environment variable with:
GEVENT_SUPPORT=True

[int19h]

To clarify, by gevent support from VSCode, do you mean "gevent": true in launch.json?

[int19h]

One thing of note is that Odoo itself has some kind of integrated profiling functionality - it calls sys.settrace:

https://github.com/odoo/odoo/blob/fa58938b3e2477f0db22cc31d4f5e6b5024f478b/odoo/tools/profiler.py#L238

It's not clear to me whether this is conditional or not, but if it runs in your repro, it would effectively override the debugger. If so, I would expect debugpy.breakpoint() to still be working - can you check if it does? And if it does, check what sys.gettrace() evaluates to in the Debug REPL or the Watch window.

[InceptionOfCode]

Yes, I mean "gevent": true inside the config.

I'll try what You asked as soon as possible.

[InceptionOfCode]

This is what I tried so far:

The function debugpy.breakpoint() works like the IDE (without the gevent: true option stops the execution but I get warnings, with the option enabled I get no warning but it doesn't work at all.

I also tried to comment the lines inside the profiler and there is no difference at all.

[InceptionOfCode]

Ok I think this is the problem.
The framework uses the preforked mode that can be debugged without problems with the "subProcess": true (default) option. Now the problem is that another subprocess using gevent is spawned (for handling the longpolling).
That's the reason why I get the warning that the debugger recognizes gevent and needs the support to be enabled.
Btw enabling it breaks the debugger and without enabling it the PC freezes because too many logs are generated.

I don't know if this is the normal behavior but a solution would be an option to disable the warning about gevent being used.

[int19h]

What's weird is that enabling gevent support makes breakpoints not work for you in the process that doesn't use it (if I understand correctly).

For the warning, I think we'd want to disable it if you explicitly set "gevent": false or GEVENT_SUPPORT=False - at this point you're deliberately expressing the intent to not debug it, so it doesn't make sense to show the warning. That part will need to be done in pydevd, though.

[InceptionOfCode]

Yes, this is the weird part. Maybe it's a problem in the way the framework spawns the processes or uses gevent, idk.

I have also tried to comment the part where the gevent process starts and the warning is gone so it seems that the problem is actually when both sub-process kinds coexist.

The option to disable the warning can be useful for now (for me it's not an issue because I don't need to debug the gevent part at the moment) but it can be also useful to make it work with both parts.

If you need other test cases just tell me.

[jeffery9]

yes. Odoo spawns the long polling process with gevent patched.
If comments out gevent:true, Odoo with preforked mode debug is worked, but raise waring message in output as

It seems that the gevent monkey-patching is being used.
Please set an environment variable with:
GEVENT_SUPPORT=True
to enable gevent support in the debugger.

[Pexers]

This workaround did the trick for me. I'm able to use the VsCode debugger while supressing gevent annoying messages. 😄

I had to overwrite Odoo's entrypoint and set the GEVENT_SUPPORT env variable from there, like so:
/usr/bin/odoo

#!/usr/bin/python3

# enable gevent support in the debugger
__import__('os').environ['GEVENT_SUPPORT'] = 'true'
# set server timezone in UTC before time module imported
__import__('os').environ['TZ'] = 'UTC'
import odoo

if __name__ == "__main__":
    odoo.cli.main()

[jpoa]

Can confirm this works. Thank you @Pexers

[jpoa]

For reference, in case it helps someone. I want to use the upstream version of Odoo and avoid conflicts (in this case with odoo-bin).

In my setup I have odoo/odoo in a folder named framework, therefore my project stands as:

project_folder/
project_folder/.venv (virtual environment for the project)
project_folder/framework (odoo/odoo, where odoo-bin is)
project_folder/addons (custom addons)
project_folder/odoo.conf (project configuration)

Based on the solution from @Pexers I have a new file project_folder/odoo_custom.py:

#!/usr/bin/env python3

import sys
sys.path.append('/path/to/project_folder/framework')

# enable gevent support in the debugger
__import__('os').environ['GEVENT_SUPPORT'] = 'true'

# set server timezone in UTC before time module imported
__import__('os').environ['TZ'] = 'UTC'

# import and run odoo-bin
if __name__ == "__main__":
    with open("/path/to/project_folder/framework/odoo-bin") as f:
        code = compile(f.read(), "odoo-bin", 'exec')
        exec(code)

and I have this launch.json file for VSCode:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Odoo - Start With Debugger",
      "type": "python",
      "python": "/path/to/project_folder/.venv/bin/python",
      "request": "launch",
      "module": "debugpy",
      "stopOnEntry": false,
      "args": [
        "--wait-for-client",
        "${workspaceRoot}/odoo_custom.py",
        "-c",
        "${workspaceRoot}/odoo.conf"
      ],
      "cwd": "${workspaceRoot}"
    },
    {
      "name": "Python - Attach debugger",
      "type": "python",
      "request": "attach",
      "port": 5678,
      "host": "localhost"
    }
  ]
}

With this I can use the debugger, use workers in Odoo and avoid issues with upstream.

[judej]

Thank you for the report. Given our current resources are working on the Python 3.12 debugger, we will not be fixing this issues in the pre Python 3.12 debugger.

[jpoa]

@judej So this issue gets considered in 3.12 or not? Sorry to ask but your statement was not clear on this and I get the impression it will just be ignored.

It is a fair thing to ignore it, I would just like to know so that I can manage my expectations.

[razvanioan]

Doesn't work if just set environment variables inside launch.json ?

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Odoo",
            "type": "debugpy",
            "request": "launch",
            "program": "${workspaceFolder}/odoo/odoo-bin",
            "args": [
                "--config=conf/odoo-server.conf",
                "--dev=xml,qweb"
            ],
            "cwd": "${workspaceRoot}",
            "console": "integratedTerminal",
            "justMyCode": false,
            "subProcess": true,
            "gevent": true,
            "env": {
                "GEVENT_SUPPORT": "true",
                "PYTEST_ADDOPTS": "--no-cov"
            }
        }
    ]
}

But even so, my debugger is still attached to only one of the subprocesses (gevent / lonpoling) and not the main ones ...

[mg-oerp]

This is still an issue including latest versions and python 3.12 so @jpoa I suspect you were correct that it's being ignored. Such a shame because I have enjoyed this editor but I think it's time to move along to something that will work for our needs.

[rchiodo]

Not sure why this was closed, but I think the thought was that 3.12 would just make this work because 3.12 doesn't use sys.trace anymore. Sounds like it didn't though.