Hi
TLDR: can’t for the life of me figure out how to get any debug info/logs from a crash affecting a running instance of the project on MacOS . Will be grateful for help with this.
Long version with context:
Working on a project that uses c++ code via GDExtensions that is crashing when running on MacOS/M4 Mac mini. This is not a issue when working on PC with Windows 10 or Linux (testing all 3 platforms to try to make a hybrid setup where I can work on the mac mini while away from my main PC) which is also kind of scary if it’s not consistentently crashing on all 3.
The editor is fine, no crashes or errors present in the Debugger, the running project just crashes on certain operations written in c++ 100% of the time.
I’m pretty sure this is down to an issue with my c++ memory management and I could eventually find it though trial end error… but I’m pretty sure I’ll eventually run into different error like this down the line so I need a way to actually get some useful call stack / debug info / logs to narrow down the reasons.
I can build the editor from source and open the project in from the command like with debug arguments but so far did not find a way to get any call stack/ error logs /debug output form the running game instance itself, just the crash.
Anybody has/knows a setup to get output from that running project instance? Is there maybe a way to debug this with VS Code or Rider?
Would be very grateful for help cause this is preventing me from moving forward, just feels to risky to just progress on Win/Linux with ought actually being able to find and address issues like this.
You need to use a debugger like GDB or LLDB. You also need to compile Godot from source, producing a build with debug symbols and limited optimizations.
Try building Godot with the options optimize=speed_trace debug_symbols=yes. You also need to build your GDExtension with debug symbols. If you use something like the example SCons template, you can provide the options target=template_debug debug_symbols=yes. This may change the name of the build artifact produced, so make sure it is listed in your .gdextension config file inside your project.
Now that you have binaries with debug symbols, you can launch Godot inside the debugger. By default, Godot launches the project browser and launches the editor in another process. You don’t want this. The debugger operates on a process (which may have many threads), but will not operate on new process forked off from it. To launch the editor (or the game) directly, you need to provide the --path parameter. So what I do is run gdb --ex=r --args godot/bin/godot.linuxbsd.editor.double.x86_64 --editor --path game/ (change paths as needed). GDB will freeze the program in the event that it crashes, and you can use the bt command to view a backtrace (along with many other commands, like setting breakpoints on functions / lines, watching variables, stepping up and down the call stack, etc).
You can also do this with LLDB, potentially plugging into it from a fancy editor using the Debug Adapter Protocol (basically like Language Server Protocol for debuggers), but that’s even more set-up and I can’t help you there.
Thanks for this advice!
I did not build the editor with optimize=speed_trace for one but a more glaring flaw in my logic was not rebuilding the GDExtension code with debug symbols etc at all, did that only with the editor.
Having some additional local issues with my macOS setup (for some reason scons stopped correctly referencing the SConstruct files between the project and engine, which used to work for me but after the newest update does not, even for a fresh setup… possibly a local issue).
Will write back once I have a chance to go back to sort out the scons issue and rebuild everything again with the proper debug setup.
Based on your second post, I would recommend creating a virtual Mac install on your Windows box and/or install a docker version of MacOS on your Windows/Linux box. It sounds like your Mac is the issue and not your code. This would quickly tell you that and then you can either fix your MacOS install or start dealing with debug stuff. My 2 cents.