MarkObjectAlloc crashes - windows target

Haxe
#1

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

crash_debug
crash_debug.jpg1920×1080 637 KB

crash_debug2
crash_debug2.jpg1920×1080 654 KB

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…”

#2

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

#3

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.

#4

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

#5

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 !

#6

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

#7

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”

#8

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.

#9

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