You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If you enable the HXCPP_GC_MOVING flag (which makes the garbage collector more efficient/able to decrease fragmentation), then you'll get intermittent crashes due to kinc storing currentPipeline to the address of a potentially moved object (and perhaps other similar safety issues).
To Reproduce
Unfortunately, this is tough to reproduce - as even if you enable the HXCPP_GC_MOVING flag, this crash will only occur if the garbage collector runs and moves the bound shader object at the wrong time. However, it's pretty easy to see how this happens from PipelineState.hx:
Binding a shader calls: @:functionCode("kinc_g4_set_pipeline(&pipeline);")
And pipeline is a struct in the actual PipelineState object, which is a haxe object that can be moved by the garbage collector: @:headerClassCode("kinc_g4_pipeline_t pipeline;")
I've identified many other cases of passing a reference of a struct in an object that can be moved which could be unsafe, but I've only seen a crash with pipelines because currentPipeline can hold a pointer to pipeline for a while.
Expected behavior
currentPipleline must be aware that the object address can change, or should be passed a pointer to a kinc_g4_pipeline_t that was created via malloc/new and therefore never touched by the garbage collector. Alternatively, the garbage collector could be paused during the renderFrame call (I think enterGCFreeZone/exitGCFreeZone can do that - although those are for multithreading).
Execution Environment:
This is on windows, but theoretically any kinc-hxcpp target should have this same problem.
The text was updated successfully, but these errors were encountered:
Describe the bug
If you enable the HXCPP_GC_MOVING flag (which makes the garbage collector more efficient/able to decrease fragmentation), then you'll get intermittent crashes due to kinc storing currentPipeline to the address of a potentially moved object (and perhaps other similar safety issues).
To Reproduce
Unfortunately, this is tough to reproduce - as even if you enable the HXCPP_GC_MOVING flag, this crash will only occur if the garbage collector runs and moves the bound shader object at the wrong time. However, it's pretty easy to see how this happens from PipelineState.hx:
Binding a shader calls:
@:functionCode("kinc_g4_set_pipeline(&pipeline);")
And pipeline is a struct in the actual PipelineState object, which is a haxe object that can be moved by the garbage collector:
@:headerClassCode("kinc_g4_pipeline_t pipeline;")
I've identified many other cases of passing a reference of a struct in an object that can be moved which could be unsafe, but I've only seen a crash with pipelines because currentPipeline can hold a pointer to pipeline for a while.
Expected behavior
currentPipleline must be aware that the object address can change, or should be passed a pointer to a kinc_g4_pipeline_t that was created via malloc/new and therefore never touched by the garbage collector. Alternatively, the garbage collector could be paused during the renderFrame call (I think enterGCFreeZone/exitGCFreeZone can do that - although those are for multithreading).
Execution Environment:
This is on windows, but theoretically any kinc-hxcpp target should have this same problem.
The text was updated successfully, but these errors were encountered: