[Godot, Linux] Some debugging issues with GDExtensions using Cpp
I am currently developing a game mostly using C++ in a GDExtension using Rider. Things are going well, except starting a debugging session for the game is finicky in Rider. I followed project setup code documented in this PR for setting up my GDExtension project to use Rider with Godot - https://github.com/godotengine/godot-cpp-template/pull/95
My project files are a little more complicated as I have two GDExtensions I'm building as static libraries linking into the third GDExtension dynamic library, but the setup is still very similar to the above PR.
The main issues I have are:
- After opening the solution in Rider, I can never start a debugging session without running the executable through Rider without debugging at least once
- Sometimes the debugging session will never start and appears to hang just before loading symbols for my GDExtension dynamic library.
- Sometimes running the debugging session will start working again after a few attempts, but I usually have to restart Rider and run the executable without the debugger again in order to have another debugging session work again.
- While debugging, “step into function” oddly doesn't work as expected and will step over the function instead. I have to manually set a breakpoint in the function I want to debug to step into it.
Some days it debugging works fine all day without issue after that first run without the debugger attached. Some days the debugger will not want to start for 10 runs in a row. Otherwise, debugging is generally stable and functional
I'm using Rider 2025.3.2 (although had identical issues on 2025.3.1) on Ubuntu 24.04.3 LTS with Godot 4.6.1-rc1 (had identical issues with Godot 4.5).
Please sign in to leave a comment.
Hello Jordan,
Apologies for the extremely late reply. Thank you for contacting Rider support and sharing your experience with us.
The issues you experience sound weird. I suggest trying the CMake approach instead of .vcxproj with scons. We added CMake support to Rider in 2026.1 EAP 7.
The godot-cpp-template works fine in my Ubuntu environment. I published this article you might find helpful: SUPPORT-A-3419 How to develop C++ GdExtensions with Rider on Linux using CMake
Note, there is a known critical issue we have already fixed: RIDER-136547 Total freeze when opening CMake Project
This issue is now fixed in the development branch, and we will deliver it as soon as possible (the current version is 2026.1 EAP 8, the fix will be in the next public 2026.1 release). As per my tests, the EAP 7 works better for a gdextension project on Linux, so that I recommend trying exactly EAP 7 (not EAP 8), to avoid the mentioned freezing problem.
And I have an update for you regarding the .vcxproj approach. You can find the pull request you mentioned is now Closed. Unfortunately, it wasn't accepted. So, while it might work in Rider upon performing manual adjustments to project files, the recommended approach for GDExtensions now is to use CMake.
(Meantime for the Godot engine itself (building engine from sources), .vcxproj works fine: one can clone Godot engine from GitHub and open it in Rider, so that Rider will suggest automatic project files generation: .sln + .vcxproj + scons).
I would appreciate it if you could try CMake with your gdextensions project and tell me how it goes. Are the mentioned issues still relevant with CMake?
Hope to hear from you soon.
Hi Dmitry,
Thanks for the update! As for the issue I was experiencing, I currently can not attempt to reproduce it because I had to RMA the CPU and motherboard of that desktop I was using. I have set up a nearly identical development environment on another (older) machine to use that is on the latest Ubuntu (25.10) and have had 100% success starting a debugging session. I'm unsure if it's related to CPU/memory speed, Ubuntu kernel differences or what. I'll be able to test the former problem on that development environment again in about a month when I receive replacement hardware.
As for CMake, I'll certainly look into it in a few days here. I have a more complicated setup in scons because I build and link multiple static libraries into one extension and the individual libraries can be conditionally built as standalone extensions themselves. I'll update you when I get a chance to try the other build system.