MarkObjectAlloc crashes - windows target

Hi all,

I’ve been having random crashes with my game for a while when compiling to windows target, while it runs perfectly when targetting flash.

I finally realized I could debug those crashes from a debug build using Visual Studio. Turns out the crashes are always very similar.

Been trying to remove a lot of things from the game in order to understand what is causing this but I have no clue… it really seems “random” as I have lots of logs and traces and it doesn’t happen consistently on a particular step in my code.

Here are 2 screenshots from visual studio when thoses crashes happen : it’s always on “MarkObjectAlloc” in GC.h or “MarkObjectAllocUnchecked” in lmmix.cpp

I never did c++ stuff and I’m kinda lost here : any idea what is happening ? What should I do to identify what’s causing the issue ? How can I get more details or anything that would lead to being able to fix this ?

I can have the game run in auto demo mode for hours on flash target, while it crashes on windows after a few minutes.

Thanks a lot for any input !

edit : forgot to translate some of the french stuff

“Exception non gérée” would be “unhandled exception”
“violation d’accès en lecture” would be “read access violation”
“violation d’accès lors de l’écriture à l’emplacement 0x…” would be “access violation while writing to location 0x…”

Are you using URLLoader or HTTPRequest much? Are you using threading?

Thanks for your reply, I’m not using HTTPRequest at all, not using URLLoader but there are still some imports of it (shouldn’t matter I guess). I’m not using threading at all.

I’m using these haxelibs :

<haxelib name="openfl" />
<haxelib name="actuate" />
<haxelib name="starling" />
<haxelib name="dragonbones" />
<haxelib name="stablexui" />
<haxelib name="msignal" />
<haxelib name="as3hx" />
<haxelib name="firetongue" />
<haxelib name="bitmapfont" />
<haxelib name="crashdumper" /> 

All are up to date, I run “haxelib update” frequently

About Starling I use starling.assets.AssetManager a lot, I load images, xmls (lots of them), jsons (DragonBones skeletons) and sounds. Once a mission is complete I clear all assets that were loaded for that mission and only keep the core assets. I tried without clearing assets but it doesn’t make a difference except on load time.

I also use some parts of the as3 CitrusEngine library that I ported to haxe : states, sound management and camera stuff essentially. I don’t use any physics, the game is about management with tactical fights (turn based, with hexs). I tried with no display except for the life bars, crashes still occur the same.

I saw a lime and hxcpp update some days ago, but I already had crashes before that. I had close to none a few months ago but not sure exactly when it started. I have mostly been doing cleaning/fixing, some AI stuff and a lot of UI stuff using stablexui after the initial port from as3.

Can you try rolling back HXCPP and doing a clean build?

Tried with HXCPP 3.4.188 with pretty much the same results : the same 2 crashes occur, although it seems to take a bit longer.

I know “doing a clean build” is supposed to be running some “-clean” param in the command line but I’m using haxedevelop and I’m not sure where to put that. I manually deleted the bin/windows folder instead.

I will do some more tests with previous version of openfl, any suggestion is welcome !

CrashDumper doesn’t give you any log error file for those crashes ?
I always debug crashes using it.

No, CrashDumper sends a report and writes a log file fine when there’s an error triggered in my code but not on those crashes.

Not saying there’s nothing wrong with my code :slight_smile: just that these errors seem to happen outside of it (although most probably caused by it somehow) ? Looks like something about garbage collection ?

I noticed since yesterday (probably after reverting to HXCPP 3.4.188 ?) I get .dmp files written in c:\users\Matse\AppData\Local\CrashDumps on every crash but I think those come from Visual Studio ?

I can open those .dmp with VS but they don’t seem to contain anything useful. Error message translates to something like “The thread attempted to read from a virtual address or to write to a virtual address for wich it doesn’t have appropriate access”

Quick follow up : it seems that the latest lime update (7.0) solved most of my issues, I think it might be related to “Fixed some cases where allocation could occur during native GC” (in the release notes)

Been doing a lot of testing before that, trying to isolate the issue but with pretty much no success. The same test could crash after a minute or after 2+ hours.

Awesome! That fix required some pretty significant architectural changes, but I hope it leads to better stability using HXCPP overall. Really happy to hear this

1 Like