*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY Kate runs debgpy on starting a session, but does not communicate to debugpy to stop and wait for setting breakpoints. STEPS TO REPRODUCE 1. Lunch kate 2. Set debugging confiugraion 3. Start debug OBSERVED RESULT The whole python code lunches with no way to set a break point. The Debug sub menu in the right click menu is also grayed out unless yous tart the debugger, which runs the whole code with no way to stop it. Even after starting, the Debug sub-menu is sometimes not grayed out, but clicking Toggle Breakpoint doesn't have any effect. EXPECTED RESULT I should be able to set a break point, start the debug and see the application stops at my breakpoint, or start the debug, set a break point, click some play button to run the program till my breakpoint. Since I have never seen kate and debugpy working together, I don't know how it used to be designed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0 ADDITIONAL INFORMATION $ kate --version kate 25.04.0 QThreadStorage: entry 10 destroyed before end of thread 0x556a008b4690 QThreadStorage: entry 9 destroyed before end of thread 0x556a008b4690 QThreadStorage: entry 1 destroyed before end of thread 0x556a008b4690 QThreadStorage: entry 0 destroyed before end of thread 0x556a008b4690 $ python3 --version Python 3.11.11 $ pip3 --version pip 25.1.1 from /usr/bin/pip (python 3.11) $ debugpy --version 0.00s - Debugger warning: It seems that frozen modules are being used, which may 0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off 0.00s - to python to disable frozen modules. 0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation. 1.8.14 .kate/dap.json file: { "dap": { "debugpy-project-venv": { "url": "Custom launcher", "run": { "command": ["python3", "-m", "debugpy.adapter"] }, "configurations": { "Launch and Pause": { "request": { "command": "launch", "program": "${file}", "stopOnEntry": true, "console": "integratedTerminal" } } } } } } Here is teh Debug Output: { "command": [ "python3", "-m", "debugpy.adapter" ], "request": { "command": "launch", "console": "integratedTerminal", "program": "", "stopOnEntry": true }, "runInTerminal": true } (telemetry) ptvsd (telemetry) debugpy server capabilities: * conditional breakpoints: supported * function breakpoints: supported * hit conditional breakpoints: supported * log points: supported * modules request: supported * goto targets request: supported * terminate request: supported * terminate debuggee: unsupported error on response: Timed out waiting for debuggee to spawn DAP backend: DAP backend 'debugpy-project-venv' failed *** connection with server closed ***
Possibly something similar to https://bugs.kde.org/show_bug.cgi?id=481691 ?
Hello, I've investigated this issue further by compiling Kate from source and tracing the debugger's execution flow. I have submitted a Merge Request (!1797) that resolves the issue by improving the user experience. **Problem Analysis:** The root cause is how the debugger configuration is gathered for DAP-based debuggers like `debugpy`. 1. The `ConfigView::currentDAPTarget()` method in `addons/gdbplugin/configview.cpp` reads the executable path directly from the `m_executable` QLineEdit widget. 2. For interpreted languages like Python, a user often won't have anything in this box, expecting the IDE to use the currently open file. 3. This results in an empty string being passed as the `program` argument to the `DapBackend`, which causes the `debugpy` adapter to exit with the `Error: missing target` message. 4. This backend crash then causes the briefly-enabled debugger UI to immediately become disabled again, creating a very confusing "catch-22" for the user. **Proposed Solution in MR !1797:** My patch fixes this by making the UI much more instructive: 1. **In `configview.cpp`:** The `currentDAPTarget()` method now checks if the executable path is empty. If it is, it displays a `QMessageBox` that clearly instructs the user to set the target path in the debugger settings. It then signals that the launch should be aborted. 2. **In `plugin_kategdb.cpp`:** The `slotDebug()` method now checks for this failure signal from `currentDAPTarget()` and cleanly aborts the launch process before the backend is even started. This approach prevents the confusing backend error and directly guides the user on the correct workflow for configuring a debug target. It makes the behavior clear and intentional. Thank you for your consideration.
Git commit 8af3900eb66fec1084427abd0354727bfbe2ff3e by Waqar Ahmed, on behalf of Aario Shahbany. Committed on 18/07/2025 at 19:43. Pushed by waqar into branch 'master'. Debugger: Improve DAP launch to prevent starting without a target Currently, trying to launch a DAP session (e.g., Python) with an empty executable path fails with an unhelpful error from the debug adapter, after temporarily enabling and then disabling the UI. This patch introduces two changes to create a better user experience: 1. In ConfigView::currentDAPTarget, if the executable path is empty, a warning dialog is now shown to the user instructing them to set the target path. The configuration is then invalidated to prevent the launch from proceeding. 2. In KatePluginGDBView::slotDebug, a check is added to ensure the configuration is valid before any debugger actions are taken. This prevents multiple warning dialogs and cleanly aborts the launch. This makes the behavior more intuitive and guides the user to the correct configuration step. Closes #505521 M +13 -3 addons/gdbplugin/configview.cpp M +1 -1 addons/gdbplugin/configview.h M +17 -1 addons/gdbplugin/plugin_kategdb.cpp https://invent.kde.org/utilities/kate/-/commit/8af3900eb66fec1084427abd0354727bfbe2ff3e