Critical Error: GCFree Zone mismatch

[codeservice]

After this commit: b4e6e20

I have rare, at random place, random time error:

Critical Error: GCFree Zone mismatch

In:
class AutoGCBlocking
{
public:
AutoGCBlocking() : mLocked( gc_try_blocking() ) { }
~AutoGCBlocking() { if (mLocked) gc_exit_blocking(); } <-- here

From: SDL2Stge -> void StartAnimation()

Observed on Windows 64 bit target.

[hughsando]

I wonder if this is the same one as HaxeFoundation/hxcpp#835
The cause would be the first foreign thread attaching (sound callback maybe?)

Could you try either setting bool gMultiThreadMode = true; in the initializer of hxcpp Immix.cpp, or alternatively adding Thread.create(function(){}) to your haxe code and seeing if this makes the problem go away.

[codeservice]

I’ll try gMultiThreadMode first and give it a time, because issue rarely happens. Reverting github GC changes helps too, only my suspicion that it only decreases chance of error, not fixing it.

…

On Sun, Aug 4, 2019 at 22:55 Hugh Sanderson ***@***.***> wrote: I wonder if this is the same one as HaxeFoundation/hxcpp#835 <HaxeFoundation/hxcpp#835> The cause would be the first foreign thread attaching (sound callback maybe?) Could you try either setting bool gMultiThreadMode = true; in the initializer of hxcpp Immix.cpp, or alternatively adding Thread.create(function(){}) to your haxe code and seeing if this makes the problem go away. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#634?email_source=notifications&email_token=AANQQG6UVQ2S2SOUCVIPOGDQC6JAVA5CNFSM4II6U6NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QRK7I#issuecomment-518067581>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANQQG2HF6WKQP7YD3UAO3DQC6JAVANCNFSM4II6U6NA> .

[codeservice]

I can confirm, setting: bool gMultiThreadMode = true; fixed issue on Win 64 bit target

[codeservice]

One more place with this issue. When I am using directRender. Didn't check this before.
I can see in display.cpp file exit and enter in potentially wrong order. Even placing enter first not fixing issue. I think this part of code not even triggering in my case, I am not using smartGc option:
if (gNmeRenderGcFree)
{
gc_exit_blocking();
onRender(renderHandle,clip,inState.mTransform);
gc_enter_blocking();
}
else
onRender(renderHandle,clip,inState.mTransform);

[hughsando]

I think this is right. Blocking is essentially "gc free zone". In the above mode, the NME render is done in a gc free zone, meaning the GC does not need to wait for the render, and the render can't do gc. However, the render callback must be done in a gc enabled zone, so we must exit block (exit gc free zone) first.