Open rainyt opened 1 month ago
-D HXCPP_GC_GENERATIONAL
-D HXCPP_CHECK_POINTER
-D HXCPP_STACK_LINE
-D HXCPP_DEBUG_LINK
-D HXCPP_STACK_TRACE
Current define.
https://github.com/HaxeFoundation/hxcpp/pull/1085 Will this be helpful?
I don't think the pinning code is relevant here.
Debugging GC errors can be a bit painful.
There are some possibilities - a bug with the marking, or incorrect usage, particularly around thread attaching and detaching.
First test is to try -debug mode and take off HXCPP_GC_GENERATIONAL - see if that helps.
Another step it to try to identify the offending object, and who owns or should own it.
If you uncomment #define HXCPP_GC_DEBUG_LEVEL 1
in Immix.cpp then the stack trace of the crash should be more informative.
Also, what library are you using? openfl/nme/etc?
in Immix.cpp then the stack trace of the crash should be more informative.
Hi, I use the OpenFL library, and if I stop using 'HXCPP_GC_GENERATIONAL', there may be a brief pause in GC requests after a few seconds, which can make users uncomfortable. I would prefer to keep 'HXCPP_GC_GENERATIONAL', but you mentioned that 'HXCPP_GC_GENERATIONAL' is a definition that may cause GC problems, and I will try to remove it and test it again.
I may not be able to debug it because I rarely encounter this issue and reproducing it is very difficult.
Yes, without a good way of reproducing, it is hard to know.
Check the performance of HXCPP_GC_DEBUG_LEVEL 1
If you find it acceptable, it could be worthwhile putting this on in production.
I also would expect some lime/openfl code on the callstack. Perhaps lime could be build with -D HXCPP_DEBUG_LINK
too, so they might show up.
:MarkObjectAllocUnchecked(hx::Object*, hx::MarkContext*) at /Users/rainy/Documents/haxelib/hxcpp/4,3,2/src/hx/gc/Immix.cpp:2200
Stack frame #232 pc 000000000307a130 /data/data/com.sxk.dark/cache/arm64-v8a-8-6-09-13/lib/arm64-v8a/libApplicationMain.so: Routine hx::MarkObjectAllocUnchecked(hx::Object*, hx::MarkContext*) at /Users/rainy/Documents/haxelib/hxcpp/4,3,2/src/hx/gc/Immix.cpp:2200
Stack frame #233 pc 000000000307a130 /data/data/com.sxk.dark/cache/arm64-v8a-8-6-09-13/lib/arm64-v8a/libApplicationMain.so: Routine hx::MarkObjectAllocUnchecked(hx::Object*, hx::MarkContext*) at /Users/rainy/Documents/haxelib/hxcpp/4,3,2/src/hx/gc/Immix.cpp:2200
Stack frame #234 pc 000000000307a130 /data/data/com.sxk.dark/cache/arm64-v8a-8-6-09-13/lib/arm64-v8a/libApplicationMain.so: Routine hx::MarkObjectAllocUnchecked(hx::Object*, hx::MarkContext*) at /Users/rainy/Documents/haxelib/hxcpp/4,3,2/src/hx/gc/Immix.cpp:2200
Stack frame #235 pc 000000000307a130 /data/data/com.sxk.dark/cache/arm64-v8a-8-6-09-13/lib/arm64-v8a/libApplicationMain.so: Routine hx::MarkObjectAllocUnchecked(hx::Object*, hx::MarkContext*) at /Users/rainy/Documents/haxelib/hxcpp/4,3,2/src/hx/gc/Immix.cpp:2200
Stack frame #236 pc 000000000307a130 /data/data/com.sxk.dark/cache/arm64-v8a-8-6-09-13/lib/arm64-v8a/libApplicationMain.so: Routine hx::MarkObjectAllocUnchecked(hx::Object*, hx::MarkContext*) at /Users/rainy/Documents/haxelib/hxcpp/4,3,2/src/hx/gc/Immix.cpp:2200
Stack frame #237 pc 000000000307a130 /data/data/com.sxk.dark/cache/arm64-v8a-8-6-09-13/lib/arm64-v8a/libApplicationMain.so: Routine hx::MarkObjectAllocUnchecked(hx::Object*, hx::MarkContext*) at /Users/rainy/Documents/haxelib/hxcpp/4,3,2/src/hx/gc/Immix.cpp:2200
When I added the loop error that occurred after HXCPP_GC_DEBUG_LEVEL 1, I didn't see any other useful information.
Yes, that is a bit of a shame. It looks like it is marking a large linked-list, and the important information (which linked list) is missing because of the stack size. It may have crashed because of a stack-overflow too, due to debug marking, which is a weakness of this method. As a side note, it is much better for hxcpp speed to use an Array, rather than a List, for almost every situation, particularly for collection speed. Do you know of large-ish linked lists, and can they be replaced? However, it might be the underlying library that is creating the list.
I'm not sure, is there any other way I can debug it? like ignore the List?
After I removed the definition of HXCPP_GC_GENERATIONAL, most crashes have disappeared.
there may be a brief pause in GC requests after a few seconds
Is there any other way to relieve it? I hope to give players a stable enough experience.
If you have any message, please let me know, thank you. @hughsando
HXCPP_GC_GENERATIONAL
increases the probability of a crash for me too :(
Hi everyone, recently after fixing the interface type crash (https://github.com/HaxeFoundation/haxe/pull/11743), the backend only has a crash related to MarkObject Alloc, which makes me think it may be related to GC. Can you help me see what could be causing this?
This error message is quite random, except for the almost identical call stack above, but the rest below is mostly random.