Open
Labels
bugSomething isn't workingSomething isn't workingneeds reproIssue has not been reproduced yetIssue has not been reproduced yet
Description
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
wxPythonanddebugpywith 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.
Reacted by Svalann
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingneeds reproIssue has not been reproduced yetIssue has not been reproduced yet




Activity
rchiodo commentedon Dec 19, 2024
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 commentedon Dec 19, 2024
It also doesn't have any problems on Windows which makes me think it's gdb related as well.
etisserant commentedon Dec 19, 2024
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 debugpywas faster to bisectdebugpyversions withpip. 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.debugpytoVersion 2024.12.0rchiodo commentedon Dec 19, 2024
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 commentedon Dec 19, 2024
Rich Chiodo (@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 commentedon Dec 19, 2024
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.
damufo commentedon Oct 28, 2025
I think same issue.
Debian 13
VS Codium Version: 1.105.17075 OS: Linux x64 6.12.48+deb13-amd64
Python debugger version 2025.14.1
Tested wxpython 4.2.1 and 4.2.2
With debugpy - graphic errors

Whithout debugpy - graphic fine
Svalann commentedon Nov 6, 2025
I’m experiencing the same issue on Windows 11 with wxPython when debugging in VS Code. Starting without debugger gives no issues.
Environment:
Symptoms:
Reverting to the older extension (2024.10.0) resolves the problem, so this appears related to changes introduced after that version.
damufo commentedon Nov 7, 2025
For linux
Version 2024.12.0 work fine
Version 2024.14.0 fail
I understand that the problem is actually at https://github.com/microsoft/vscode-python-debugger
jensgoe commentedon Nov 8, 2026
same for me, i use wxPython 4.3.2 and getting these log output in the console:
D:\a\Phoenix\Phoenix\dist\wxpython-src\ext\wxWidgets\include\wx/msw/private/dc.h(74): 'SetTextColor' failed with error 0x00000057 (Falscher Parameter.).
D:\a\Phoenix\Phoenix\dist\wxpython-src\ext\wxWidgets\include\wx/msw/private/dc.h(87): 'SetBkColor' failed with error 0x00000057 (Falscher Parameter.).
....\src\msw\dc.cpp(2529): 'BitBlt' failed with error 0x00000006 (Das Handle ist ung³ltig.).
D:\a\Phoenix\Phoenix\dist\wxpython-src\ext\wxWidgets\include\wx/msw/private/dc.h(74): 'SetTextColor' failed with error 0x00000057 (Falscher Parameter.).
D:\a\Phoenix\Phoenix\dist\wxpython-src\ext\wxWidgets\include\wx/msw/private/dc.h(87): 'SetBkColor' failed with error 0x00000057 (Falscher Parameter.).
....\src\msw\dc.cpp(2529): 'BitBlt' failed with error 0x00000006 (Das Handle ist ung³ltig.).
so it seems the dc window handles gets corrupted?!