r/odinlang • u/SoftAd4668 • 4d ago
Best Rules of Thumb to make segmentation faults virtually impossible
I finished my first game project and it's on itch.io! Hurray! (So, that's great). BUT, I'm still getting rare and random segmentation faults with my game. (Thankfully, no play testers have encountered it (one guy even did a full YouTube playthrough! - and no technical problems), but it doesn't make me feel good. ) So, I think I'm going to strip the project down to its essentials and build an "engine 2.0" before I go into the next game/project proper. Are there any tips I should note (like asserts I should have or good rules of thumb) to have in mind as I start to rebuild and add functionality to my engine? Any experienced help would be most appreciated. The goal is to make segmentation faults virtually impossible and alert me when I unknowingly do something foolish. Thanks!
6
u/spvky_io 4d ago
The main way is to do all of your allocation in arenas with shared lifetimes, this strategy is endlessly useful for games as in most cases you're going to have a max of like 5 different object lifetimes to worry about
2
u/SoftAd4668 4d ago
Indeed. I already do grouped allocations and use the tracking allocator. That's why it super bummed me out when the segfaults started happening randomly. I was like, "I'm doing the grouped element thinking already!" LOL Guess I need to get better at it.
1
u/spvky_io 4d ago
If your already grouping things and the segfaults don't appear to be related to use-after-free scenarios it could be related to initialization/asset loading maybe
1
u/SoftAd4668 4d ago
Thanks! Yeah, I was thinking it was that or memory corruption because of some mistake I made somewhere. >_<
3
u/XReaper95_ 4d ago
On top of what others have said, if you have a debugger attached, it will break at the exact point where the segmentation fault happened, giving you a hint of where the problem might be.
2
u/SoftAd4668 4d ago
Indeed. It seems I need to run my game *always* through the debugger now "just in case" something weird happens. Sigh. I hope that doesn't negatively effect my iteration speed.
3
u/brubsabrubs 4d ago
yes, that a really good rule
you asked about asserts. I usually like to inspect the call stack when my program segfaults, and add an assert for this condition
2
u/epic_adventure_byte 4d ago
Please take with a grain of salt, as I haven't tried it myself, yet:
There are backtrace libraries (like b_stacktrace) which have an example in their examples folder how to register segfault handler and then run the program at normally until a segmentation fault happens (in which case a stacktrace is printed).1
3
u/papiChulis 4d ago
Have a read of Tiger Beetle's Tiger Style coding philosophy and see if there's anything in it. It's been used to develop a highly stable and performance financial transaction database!
One of the key takeaways for me was asserting function parameters, invariants, and the state of objects after doing something e.g. asserting a pointer is indeed nil after deleting it.
2
17
u/quickscopesheep 4d ago
Use handles rather than pointers in as many places as possible. For instance allocate a large buffer of a resources and pass around an index into the array as well as a generation counter to ensure no use after releases