Windows target crash if executable path contain non-English characters

Help
#1

I was testing an empty Haxeflixel template using “lime test windows”
and everything went smoothly, “hello world” window shows up

but
if I use “lime build windows”, and then double click on executable I just compiled
it will throw me “XXX.exe has stopped working”
exception code c0000005

the weird thing I found is that If I simply move executable to other folder which path are all English characters, the problem just disappeared

also if I add -debug when compiling then this problem is gone again

Originally I thought this is Haxeflixel’s problem but when I tested my old project that only use OpenFL, the result is same. I think the problems is probably more related to Lime or OpenFL

All library I’m using are latest version
I’m using Visual Studio Code with VS 2017 build tool

#2

Hi, I remember something like this happening to my app with saved files in applicationStorageDirectory when username contained french characters with accent. If I remember correctly @singmajesty told me it was an issue with hxcpp.

I was hoping this would be fixed by now but haven’t tested, have you tried with latest hxcpp ?

edit : since your libs are up to date that probably means the issue is still there… I don’t see any issue open on that subject ( https://github.com/HaxeFoundation/hxcpp/issues?page=1&q=is%3Aissue+is%3Aopen ), I think we should create one ?

#3

so It’s been 2 weeks and there’s no lead for this bug
but I found Hashlink and the performance is almost same as hxcpp

I guess I’ll just target Hashlink instead of trying to fix broken Windows target with -release

ps: I don’t know why but haxe seems to be have many issues related to UTF-8 path
like auto completion is straight up broken in VSC if my project folder path contains chinese character

#4

Somehow I found a better workaround
If I compile it with HXCPP_STACK_TRACE, the executable will run just fine in release mode

I hope the only downside is bloated file size and no performance hit

1 Like
#5

Hit the same error with win10 startup and tried your workaround and it is only partially valid. It indeed helps with SOME non-askii paths, but lengthier sequences still produce startup crash.

But i found the root of the problem (i think). It is a ParseCommandLine from StdLibs.cpp, clearly visible from stacktrace. And seems the fix should be easy (imho). Filed an issue - Crash with executables for windows target when non-ASCII chars present in exe path · Issue #1019 · HaxeFoundation/hxcpp · GitHub @Matse

#6

I would gladly help… if I wasn’t a complete noob at c++ :sweat_smile:

Not sure knowing c++ would be enough : it might require some knowledge of how things work internally.

I know that a few years ago trying to write to a file with a path containing latin characters such as “éèà” etc would lead to a crash, and this was fixed, maybe retrieving the corresponding commit would give us some light ?

#7

I see, sorry to bother! Better leave this to hxcpp devs then. Good news method is quite “isolated”, so fix should not lead to full rewrites…

The overall filesystem stuff with unicode-charged paths works ok (files can be read/saved/folders walked/etc), the only problem is paths are not readable as string (unicode chars replaced with ascii garbage).

And this problem seems to be single reason for crashes on start, i got fully working app just by removing offensive loop from local hxcpp code (since argument parsing was not used by me at all)

#8

No problem mate, that’s an issue I’m highly interested in : I wish I could do something !

Yup thanks for sharing that, I don’t use command line params either so far so that would fix the issue for me but yeah, I’d much prefer those character issues solved 100% once and for all ^^

1 Like
#9

Just for the note: the crash could also happen when path to assets contains non-ascii.

See

1 Like