How to debug random GC.h crash on windows target?

Hi all,

My game runs flawlessly on AIR target (which is my test target), but crashes randomly when I run it on windows target.
When the crash happens Windows gives me the option to debug it in Visual Studio and it’s always the same error on the very same line, here is a screenshot :

my system’s language is french, the error message means “unhandled exception at 0x… in SuperAgency.exe : 0x… access violation while reading location 0x…”

I never touched c++ so I understand that it’s something about garbage collection, but I’m lost.

When I look at the local vars, inside __inCtx.marking.stack I see a bunch of Starling images and some matrixes but I have no idea what it means : are those objects about to be garbage-collected or something ?

I have a demo mode where the game runs on its own : it loads an arena, the AI characters fights to death, then everything gets cleared / pooled, then it loads an arena again etc rinse repeat.

On AIR I can have this demo mode running for hours but on windows target it will end up crashing randomly : it can crash after 4 fights or 15+ fights, there doesn’t seem to be any “rule”. The point at which it crashes also looks random : it can happen at any point during the fight.

Lately I put a lot of efforts hunting the slightest memory leak, and most of the objects are pooled. The game uses openFL, Starling, dragonbones, msignal, Actuate, StablexUI, firetongue and crashdumper (which fails at catching the crash)

Any help with this would be very welcome : is there a way to get more info about the crash ? Any tip or advice about what I should do to solve it ?

Thanks a lot !

What versions haxe, hxcpp, openfl, and lime are you using? Compiling 64bit or 32?

Oh sorry, should have specified that :

haxe 4.1.0 (had the same issue with 4.0.3)
hxcpp 4.1.1
lime 7.7.0
openfl 8.9.6

as to 32 or 64 bits I have to say I don’t know : I’m using haxedevelop, I select windows target and hit F5… I’d love to learn more though

my system is 64 bit, I installed haxe 64 bit

When it compiles, here is the output I see

Building SuperAgency
Running Pre-Build Command Line…
cmd: “C:\HaxeToolkit\haxe/haxelib” run lime build “project.xml” windows -debug -Dfdb

Running process: C:\Program Files (x86)\HaxeDevelop\Tools\fdbuild\fdbuild.exe “D:_Dev_Project\SuperAgency\dev\SuperAgency\SuperAgency.hxproj” -ipc ed54966c-b3c7-40c6-813c-dcac59d7c84c -version “4.1.0” -compiler “C:\HaxeToolkit\haxe” -library “C:\Program Files (x86)\HaxeDevelop\Library” -target “windows”

cl.exe -Iinclude -nologo /WX- /fp:precise -DHX_WINDOWS -GR -Od(optim-std) -Zi(optim-std) -FdD:_Dev_Project\SuperAgency\dev\SuperAgency\bin\windows\obj\obj/msvc1964-debug-nc/vc.pdb(optim-std) -Zi(debug) -FdD:_Dev_Project\SuperAgency\dev\SuperAgency\bin\windows\obj\obj/msvc1964-debug-nc/vc.pdb(debug) -Od(debug) -O2(release) -bigobj -Os(optim-size) -FS -Oy- -c -EHs -GS- -IC:/HaxeToolkit/haxe/lib/hxcpp/4,1,1/include -DHXCPP_DEBUG -DHXCPP_M64 -DHXCPP_VISIT_ALLOCS(haxe) -DHXCPP_CHECK_POINTER(haxe) -DHXCPP_STACK_TRACE(haxe) -DHXCPP_STACK_LINE(haxe) -DHX_SMART_STRINGS(haxe) -DHXCPP_API_LEVEL=400(haxe) -D_CRT_SECURE_NO_DEPRECATE -D_ALLOW_MSC_VER_MISMATCH -D_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH -DHX_WIN_MAIN(main) -wd4996 … tags=[haxe,static]

Thanks

I finally solved this yesterday, turned out the issue came from dragonbones lib.

I still don’t know how to debug the crash I described, as I know nothing about c++. I was working on the game’s options and figured “combat speed” would be a nice one to have, and added it pretty easily using starling’s Juggler and dragonbones WorldClock. This gave me the idea to boost it up to a stupidly high value like 20 to see if it would help reproduce the crash a lot faster, which worked.

From there I added some config to be able to disable my visual FX system, which was not at fault, then did the same to disable dragonbones - displaying starling quads instead. This allowed me to see that the crash never occurred with dragonbones turned off.

I started looking into dragonbones code and saw some things that looked weird, such as doing this to clear a map :

for (k in boneTimelines.keys())
{
	boneTimelines[k].returnToPool();
	boneTimelines.remove(k);
}

Unless I’m missing something this is gonna leave almost half the entries inside boneTimeLines

I started modifying these parts but it didn’t seem to help in my case. Everytime I looked at my crashes in Visual Studio’s debugger I would see a lot of Vectors so I thought why not replacing all Vectors in dragonbones with Arrays… and after that no more crashes :slight_smile: couldn’t believe it at first but I triple-checked and it’s definetely not there anymore (yay !)

I’m not sure what the issue is exactly : dragonbones does a lot of

Vector.fixed = false;
(add or remove stuff)
Vector.fixed = true;

It also uses a lot of
Vector.length = 0;
and
Vector.length = desiredLength;

I think the crash comes from one of these, or a combination it’s hard to tell.

Also I think I have only seen the crash occurring when “disposing” Armature instances : everything gets returned to pool to be re-used later.

Finally there is still a memory leak (at least when used with Starling) occurring on windows target (I guess it happens on any c++ target but only tested Windows so far). My changes didn’t seem to help with it. I will eventually try to find it out but for now it’s small enough that I can live with it :stuck_out_tongue:

If anyone is interested, the modified version of dragonbones is available here : https://github.com/MatseFR/dragonbones

warning 1 : I only changed the core and starling parts, didn’t change openFL Fixel or Flash parts (I’ll do it if someone needs it, let me know)

warning 2 : I like to have control over the Armatures getting added to the WorldClock so I disabled the code that does it automatically in StarlingFactory

I’ll probably create a thread about those issues with Dragonbones later, hopefully with more precision