WxPython/GTK3 graphical glitches starting with debugpy 1.8.8

[etisserant]

Environment data

• debugpy version: 1.8.8 and greater
• OS and version: ubuntu 24.04
• Python version 3.12.3
• Tested with WxPython version 4.2.1 and 4.2.2

Actual behavior

WxWidget GUI isn't drawn properly when debugger is connected. Some widgets are not drawn at all, and damages are not systematically repaired when scaling window. Window top becomes kind of transparent and shows non-updated pixels from background that follow when dragging window.

Expected behavior

When connecting debugger, WxPython draws normally.

expected	actual

Steps to reproduce:

• install wxPython and debugpy with PIP
• download WxPython demo
• run it with python -m "debugpy" --listen localhost:5678 demo.py
• attach with vscode

        {
            "name": "Attach",
            "type": "python",
            "request": "attach",
            "connect": {
                "port": 5678,
            }
        }
  
  
  

With pypi's debugpy==1.8.7 problem doesn't occur.

[rchiodo]

Is there a reason you need to attach? It works fine for me launching it. In Linux attach uses GDB under the covers, that might be interfering with the thread that does the drawing.

[rchiodo]

It also doesn't have any problems on Windows which makes me think it's gdb related as well.

[etisserant]

It happens also if I launch directly from vscode python debug extension, with or without "guiEventLoop": "wx" in launch.json specs.

The reason why I listen and connect on port 5678 is that invoking python manually with -m debugpy was faster to bisect debugpy versions with pip. Dunno why this is named "attach" in launch.json, there is no gdb PID attaching involved in my case.

It works if I downgrade ms-python.debugpy to Version 2024.12.0

[rchiodo]

Oh yeah you're right, it's not actually an attach. Not sure how 1.8.8 could have broken something so specific. It was us removing checked in binaries (only used in attach) and some minor bug fixes.

v1.8.7...v1.8.8

[AdamYoblick]

@rchiodo The only thing I can think of regarding the pydevd binaries that we now build (instead of ingesting) from the pydevd repo is the environment in which they are built.

The image in the container we use to build the manylinux wheels has very old components, by design, for backcompat.

When I was refactoring the build, I got errors when building the manylinux wheels because the pydevd binaries we built outside of this container used dependencies that were much newer than those in the container.

So the solution was to move the compilation of the pydevd binaries to the same container used by the wheel generation. This made the build happy.

It's certainly possible that this caused unintended side effects when these binaries are used by Debugpy in a Linux environment. Our tests didn't see any failures through, but this might be an edge case?

[rchiodo]

That's what I initially thought - it was the new binaries we made. But this isn't an attach scenario, so those binaries aren't used.