[Windows] Packaged (native) app fails to launch when on a non-ISO-8859-1 path

[ygunayer]

My Windows username has a Turkish character in it (thanks for using my name and not asking me at all, Microsoft), and when I run the app (the .exe version) from that path, it fails. If I move it to a path that only contains ISO-8859-1 characters (even non-ASCII ones such as ü, ö or ç) it works just fine, but anything other than that, it fails. The .jar version, however, works everywhere regardless of the characters in the path.

Though not informative, here's an error log from the event viewer:

Faulting application name: HotSLogs UploaderFX.exe, version: 0.0.0.0, time stamp: 0x55760121
Faulting module name: packager.dll, version: 0.0.0.0, time stamp: 0x55760127
Exception code: 0xc0000005
Fault offset: 0x00000000000148eb
Faulting process id: 0x2600
Faulting application start time: 0x01d0cb025d184f72
Faulting application path: C:\Users\Yalın\AppData\Local\HotSLogs UploaderFX\HotSLogs UploaderFX.exe
Faulting module path: C:\Users\Yalın\AppData\Local\HotSLogs UploaderFX\packager.dll
Report Id: 06efbcd3-e5b4-486d-81d5-ded8786a08c9
Faulting package full name: 
Faulting package-relative application ID: 

You should be able to reproduce the issue by using ığ or 日本 as the containing folder name.

This is probably an error on the packager's end, but I don't know how to debug nor how to fix this. I'd like to, though, so any help would be appreciated.

[eivindveg]

I may be to blame. 0xc0000005 is AccessViolationException. It's possible I should specify UTF-8 encoding for the URLs when loading resources. It may also be DataFX failing to specify such. Could you start the application in cmd.exe to trigger the crash and see if it outputs a Java stacktrace?

[ygunayer]

Nope, sorry, nothing at all. It was one of the first things I've tried but I forgot to mention it.

I still blame the native packager, though. Since I can reproduce the issue at any time I'd be happy to look into it, but I don't know a thing about native packaging nor JavaFX. Any keywords you might suggest I look into?

[eivindveg]

I agree. If it were part of my code, there should've been a stacktrace for critical errors. It may be the javafx-maven-plugin, or it may be the javafx bundler itself. I'll look into it, and appreciate any pointers you uncover. Otherwise, I too am blank.

[eivindveg]

Hello,

I've changed my Inno Setup installation to use unicode. Could you please try this build? https://drive.google.com/file/d/0B1YR9l10StB3VWJ5VnBUbHBSODg/view?usp=sharing

[eivindveg]

Or also the normal 1.2 release.

[ygunayer]

Sorry, still nothing. I tried to dump a few things on the console right at the beginning of the main method, but the execution doesn't even reach that point. The JAR itself still works, though, and so does the Gradle-generated distro (which is just a batch file that wraps the JAR anyway), but then again, neither of them are native packages anyway.

But anyway, I think we can now confirm that this is no longer relevant to HotSUploader in particular because I've just found out that someone's recently created reported the exact same issue on OpenJDK's bug tracker: https://bugs.openjdk.java.net/browse/JDK-8087422

It's listed as a minor issue and there hasn't been any update in the last 3 months, so I guess we can just list this as a known bug caused by JavaFX itself, and ship a standalone version (in addition to the setup) for anyone who might have the issue.

[eivindveg]

Could you try building your own distribution to see if it's in any way dependent on the host?

[ygunayer]

I did, but it didn't help. I also tried running the build through a very basic C# app by starting the Java process with the appropriate arguments (classpath, task names, etc.) but it didn't help either.

As expected, though, the very same app worked perfectly when I used it as a host for the prebuilt JAR file by basically running the java process with the arguments -jar app/HotSUploader-jfx.rar. For the source code see the Gist at https://gist.github.com/ygunayer/d304ff0dc2d09857e86a

So we can either wait until the issue gets fixed by the guys at JavaFX, or stop using it as the native host (at least for Windows). Going with the second approach means that we'll have to use another language within the project, which means changing the build step, and I don't know how complicated things would get then.

[eivindveg]

I think this issue underlines the importance of providing the fat-jars moving forward. I'll see if I can set up the javafx-maven-plugin to allow system wide installs, or submit a pull request to them which allows it.