hxcpp
hxcpp copied to clipboard
Generational Garbage Collection crashing on Non-Microsoft things?
Tested all kinds of variants (debug/release, 32bit/64bit) on Android and Switch and my example from earlier (attached it again for convenience) quickly crashes in MarkAlloc in all of them. Only tested with Kha so far because I couldn't yet convince hxcpp to correctly detect the Android SDK. hxcpp_test2.zip
Given it is a processor thing, it could be the register capture. You could try uncommenting the HXCPP_CAPTURE_SETJMP define in GcRegCapture.h and see if that fixes it.
No observable change in behaviour with HXCPP_CAPTURE_SETJMP enabled on neither Android nor Switch sadly.
Hey, looks like this also crashes on Linux and macOS according to my Kha-friends on IRC. But it works fine for me on Windows 🤔 PS4-test incoming...
Also crashing on PS4, in MarkObjectAlloc this time. Looks like I only tested on Windows and Xbox recently. I'm still confused, generational is now the default in Kha for a while.
Another platform difference is: https://github.com/HaxeFoundation/hxcpp/blob/master/src/hx/gc/Immix.cpp#L91
Which works around aggressive compiler optimizations (only seen on windows - but maybe elsewhere now?) You could try enabling this unconditionally.
That actually fixes the sample on PS4 and Switch in debug and release modes. Yay! Mega-thanks! Compiling that game now...
CrossCode is working fine again on PS4 and Switch \o/
Nice! I guess I have to enable that on all platforms. Are you doing any funky multiple inheritance mixing cpp and hxcpp? Or maybe this optimization has found its way into the various clang chains.
No funky inheritance here and the original sample (in the first comment) still seems to work fine for testing this. Switch and PS4 both use clang but there was also somebody telling me that it didn't work on Linux which should be GCC.
Ok - I was just trying to work out what has changed, but now I think of it, it could be caused by the write-barrier code making it more convenient for the compiler to store an offset pointer, in which case if could be the generational code indirectly creating the issue. I would still like to confirm this for my own satisfaction, but the fix looks good for now.