Can’t debug segfault in multiplayer game server
#Can’t debug segfault in multiplayer game server
warm dagger
trim dirge
Well, iirc valgrind should just show you the stack trace to the segfault no?
trim dirge
It could be many things, idk anything about server stuff though. But there's a lot of things you can set for valgrind to get a more elaborate output
hearty sail
Can you look more though those "possibly lost" messages from start to end? It indicates w memory leak
Also you might want to test this on newer Godot versions in case memory leak had been patched
You can also log metrics such as memory usage from the server itself
narrow thicket
Can you attach the coredump file (or upload it somewhere)?
hearty sail
Or run the application in gdb with it and step though the commands until the segfault
narrow thicket
If you really don't want to compile a debug build yourself, I could build one for you since I have a working environment already. Let me know if you'd like to try that, it would give you more meaningful output in all of the things above (the ?? are due to symbols being stripped from the release build engine)
narrow thicket
A debug build has all of the internal symbols from the c++ code, the problem with your gdb output etc is that because there are no symbols included in release builds, instead of showing function names it just shows "??" - with a debug build you should see the exact function names and source files that the segfault is happening on in the stack trace
If it's saving a core dump there should be a file somewhere on your system that contains the complete debug data, ie not human readable output but a file, which allows gdb to "simulate" the crash. But idk debian so not sure where it would be
narrow thicket
Sure, 3.5 stable server build?
narrow thicket
Should get better trace output with this. Warning: it's ~400mb unzipped, vs 14mb for the official release, that's how much useful debugging info is removed when building release target and stripping the binary lol. This also has remote debugging enabled, so another thing you could try with this build is connecting your local machine's godot editor debugger to the running server if your vm's network allows for it (think there are command line options or some other config to wait for debugger connections for a timeout so you have time to connect before the crash)
narrow thicket
Hmm it should be safe but tbh i didnt realise itd be an issue, is that the latest glibc debian provides or is there an update available from the main repos? If theres a main repo update then itll be safe, debian are probably the most conservative distro when it comes to updates becoming available. I built it on arch so i can see how it would be an issue! I can rebuild it in a vm or something though, if youre not sure about upgrading
narrow thicket
Yeah sure, will do it in a sec, takes a bit longer to build in a vm but ill let you know when its done
narrow thicket
Didnt get around to it last night, but just installed a fresh debian 11 vm so will get around to it shortly
narrow thicket
here you go @warm dagger removed the old release download and added new one built against glibc 2.31-13: https://github.com/lewiji/godot/releases/tag/3.5-stable
narrow thicket
great news! you're welcome
narrow thicket
The cloud was a mistake lol, we should never have gone full cloud
hearty sail
What kind of error message was it in the end?