2

I am trying to run jpackage with a bare bones Gradle JavaFX application mostly to try things out. There is nothing special about it, its the IntelliJ JavaFX sample with Gradle added in. The application runs fine with gradlew clean build run. However, when creating a package with gradlew jpackage the resulting exe crashes instantly and creates an hs_err_pid.

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=1132, tid=15340
#
# JRE version:  (15.0.2+10) (build )
# Java VM: OpenJDK 64-Bit Server VM (15.0.2+10, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  0x0000000000000000

See full output here: https://pastebin.com/LgbSFa5L

I've tried the answers on a similar question but they did not work.

  • Copying zip.dll from {app}\runtime\bin to {app}\
  • Trying other JDKs
    • AdoptOpenJDK 11
    • AdoptOpenJDK 14
    • AdoptOpenJDK 15
    • BellSoft Liberica JDK 15

build.gradle looks like this

// Setup Gradle
plugins {
    id "application"
    id "org.beryx.runtime" version "1.12.2"
    id "org.openjfx.javafxplugin" version '0.0.9'
}

repositories {
    mavenCentral()
    jcenter()
}

// Setup application, dependencies
group = "io.mattw.sample"
sourceCompatibility = 15
targetCompatibility = 15

application {
    mainClassName = "io.mattw.sample.Main"
}

javafx {
    version = 15
    modules = ["javafx.base", "javafx.controls", "javafx.fxml"]
}

dependencies {

}

// Setup release
// https://simply-how.com/custom-java-runtime
runtime {
    addOptions("--strip-debug", "--compress", "2", "--no-header-files", "--no-man-pages")
}

tasks.runtime.doLast {
    copy {
        from("src/main/resources")
        into("$buildDir/image/bin")
    }
}

Edit:

When running the exe with WinDbg (preview), I get the following output. Possibly relevant that I have Java 8 installed normally though I'd expect it to use the bundled SDK and not the systems.

Microsoft (R) Windows Debugger Version 10.0.21306.1007 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\gradle-test-javafx.exe

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
ModLoad: 00007ff6`995d0000 00007ff6`9963f000   image00007ff6`995d0000
ModLoad: 00007ffc`36450000 00007ffc`36646000   ntdll.dll
ModLoad: 00007ffc`35320000 00007ffc`353dd000   C:\WINDOWS\System32\KERNEL32.DLL
ModLoad: 00007ffc`33d90000 00007ffc`34059000   C:\WINDOWS\System32\KERNELBASE.dll
ModLoad: 00007ffc`36210000 00007ffc`363b0000   C:\WINDOWS\System32\USER32.dll
ModLoad: 00007ffc`33d30000 00007ffc`33d52000   C:\WINDOWS\System32\win32u.dll
ModLoad: 00007ffc`346f0000 00007ffc`3471a000   C:\WINDOWS\System32\GDI32.dll
ModLoad: 00007ffc`343a0000 00007ffc`344ab000   C:\WINDOWS\System32\gdi32full.dll
ModLoad: 00007ffc`33c90000 00007ffc`33d2d000   C:\WINDOWS\System32\msvcp_win.dll
ModLoad: 00007ffc`33b90000 00007ffc`33c90000   C:\WINDOWS\System32\ucrtbase.dll
ModLoad: 00007ffc`35ac0000 00007ffc`36202000   C:\WINDOWS\System32\SHELL32.dll
(4ad0.33e0): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffc`36520670 cc              int     3
0:000> g
ModLoad: 00007ffc`355c0000 00007ffc`355f0000   C:\WINDOWS\System32\IMM32.DLL
ModLoad: 00007ffc`34ba0000 00007ffc`34c4e000   C:\WINDOWS\System32\shcore.dll
ModLoad: 00007ffc`35a20000 00007ffc`35abe000   C:\WINDOWS\System32\msvcrt.dll
ModLoad: 00007ffc`34840000 00007ffc`34b96000   C:\WINDOWS\System32\combase.dll
ModLoad: 00007ffc`35720000 00007ffc`3584b000   C:\WINDOWS\System32\RPCRT4.dll
ModLoad: 00007ffc`11d50000 00007ffc`11d68000   C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\runtime\bin\jli.dll
ModLoad: 00007ffc`224e0000 00007ffc`22590000   C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.19041.488_none_4238de57f6b64d28\COMCTL32.dll
ModLoad: 00007ffc`22cb0000 00007ffc`22cc9000   C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll
ModLoad: 00007ffc`34c50000 00007ffc`34cfc000   C:\WINDOWS\System32\ADVAPI32.dll
ModLoad: 00007ffc`35520000 00007ffc`355bc000   C:\WINDOWS\System32\sechost.dll
ModLoad: 00007ffc`10080000 00007ffc`10095000   C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\runtime\bin\vcruntime140.dll
ModLoad: 00007ffb`f76b0000 00007ffb`f774b000   C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\runtime\bin\msvcp140.dll
ModLoad: 00007ffb`a5030000 00007ffb`a5bbf000   C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\runtime\bin\server\jvm.dll
ModLoad: 00007ffc`34630000 00007ffc`34638000   C:\WINDOWS\System32\PSAPI.DLL
ModLoad: 00007ffc`1ff10000 00007ffc`1ff19000   C:\WINDOWS\SYSTEM32\WSOCK32.dll
ModLoad: 00007ffc`32a70000 00007ffc`32a7a000   C:\WINDOWS\SYSTEM32\VERSION.dll
ModLoad: 00007ffc`261f0000 00007ffc`26217000   C:\WINDOWS\SYSTEM32\WINMM.dll
ModLoad: 00007ffc`35870000 00007ffc`358db000   C:\WINDOWS\System32\WS2_32.dll
ModLoad: 0000014c`22330000 0000014c`2239b000   C:\WINDOWS\System32\ws2_32.DLL
ModLoad: 00007ffc`32a30000 00007ffc`32a42000   C:\WINDOWS\SYSTEM32\kernel.appcore.dll
ModLoad: 00007ffc`2acf0000 00007ffc`2acfa000   C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\runtime\bin\jimage.dll
ModLoad: 00007ffc`22590000 00007ffc`22774000   C:\WINDOWS\SYSTEM32\DBGHELP.DLL
ModLoad: 00007ffc`21be0000 00007ffc`21c0c000   C:\WINDOWS\SYSTEM32\dbgcore.DLL
ModLoad: 00007ffc`34060000 00007ffc`340e0000   C:\WINDOWS\System32\bcryptPrimitives.dll
ModLoad: 00007ffc`09f50000 00007ffc`09f75000   C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\runtime\bin\java.dll
(4ad0.30c4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
0000014c`23890969 8b06            mov     eax,dword ptr [rsi] ds:00000000`00000000=????????
0:004> g
(4ad0.30c4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for C:\GitHub\gradle-test-javafx\build\jpackage\gradle-test-javafx\runtime\bin\jimage.dll
00000000`00000000 ??              ???
0:004> g
ntdll!NtTerminateProcess+0x14:
00007ffc`364ecba4 c3              ret
Matthew Wright
  • 1,485
  • 1
  • 14
  • 38
  • Could you try to see if running the app with the produced runtime image manually works? `.\build\jpackage\{app}\runtime\bin\java.exe -cp .\build\jpackage\{app}\app\{app}.jar io.mattw.sample.Main` The problem might just be in the .exe launcher, in which case it could be a problem with the wixtoolset version you are using. – Jorn Vernee Mar 07 '21 at 16:24
  • Seem to be getting an error that it couldn't find or load the main class. Tried added `"--main-class io.mattw.sample.Main"` to the `runtime { addOptions() }` list and now the `gradlew jpackage --info` command is erroring that it can't find modules exporting multiple javafx modules. I'm not trying to create a modular application, just a simple javafx app with a bundled runtime. My installed WiX Toolset seems to be 3.11.2.4516. – Matthew Wright Mar 07 '21 at 16:43
  • "erroring that it can't find modules exporting multiple javafx modules" I'm not sure what you mean here, but AFAIK javafx modules have to be put on the module path, and since your application is non-modular, you might be missing the needed `--add-modules` directives (not sure how this is handled by Liberica though). It would be useful if you can include the error in the body of the question as well. – Jorn Vernee Mar 07 '21 at 16:57
  • It seems that adding that `--main-class` option was invalid, `Error: unknown option: --main-class io.mattw.sample.Main` and removing it makes jpackage work again. I'll include the error for trying to run the runtime image manually. – Matthew Wright Mar 07 '21 at 16:59
  • It can't find the main class because it doesn't seem to be able to find javafx. However, in the jpackage/{app}/app folder I see the javafx base, controls, fxml jars – Matthew Wright Mar 07 '21 at 17:03
  • If you're not running with Liberica you have to add the javafx jars to the module path manually when running. I think the command: `.\build\jpackage\gradle-test-javafx\runtime\bin\java.exe -cp .\build\jpackage\gradle-test-javafx\app\gradle-test-javafx.jar --module-path .\build\jpackage\gradle-test-javafx\app --add-modules javafx.base,javafx.controls,javafx.fxml io.mattw.sample.Main` should work for you. – Jorn Vernee Mar 07 '21 at 17:21
  • Ah yup, I did switch from Liberica back to AdoptOpenJdk and that command works, application runs without issue. Problem with WiX then? – Matthew Wright Mar 07 '21 at 17:25
  • I have the same version of wix, but have not been able to reproduce your crash so far. Looking at the error message again, on second thought, I don't think it's a problem with wix, since it's a VM crash, which means you are getting into the jpackage or VM code. I've been able to make it work with Liberica so far (will post an answer for that). I suspect that maybe the problem with non-liberica stems from the launcher not adding the needed module-path and add-modules flags. – Jorn Vernee Mar 07 '21 at 17:35
  • I switched back to Liberica and when trying to run the application manually, it seems to get farther but still errors – Matthew Wright Mar 07 '21 at 17:43
  • Removed the edit, I forgot to restart a new terminal to use the liberica jdk. I switched back to Liberica and running the jpackage build manually works still. However, trying to use the generated exe still produces the jvm crash. – Matthew Wright Mar 07 '21 at 17:48
  • I am also currently struggling with a similar issue. I created a jpackage instaler, using a jlink runtime, and it works fine on my pc. However, when I tried to run it on a different machine it crashed imedietly and produced the same .log file as yours. It runs fine trough the .bat launcher script in the /bin folder though. Have you maneged to fix your issue? – FlickIt Mar 08 '21 at 09:29

3 Answers3

2

With Liberica I'm able to make it work by adding the following line:

runtime {
    addOptions("--strip-debug", "--compress", "2", "--no-header-files", "--no-man-pages")
    addModules("javafx.base", "javafx.controls", "javafx.fxml") // <----
}

Without that, it seems like the javafx.controls module is not added to the generated runtime image (you can check that with runtime\bin\java.exe --list-modules).

Running the application manually, as well as through the generated exe works after that.


Without Liberica, I was able to get some more information by adding the --win-console option to jpackage as follows:

runtime {
    addOptions("--strip-debug", "--compress", "2", "--no-header-files", "--no-man-pages")

    jpackage {
        imageOptions = ["--win-console"] // <---
    }
}

Running the generated exe results in

Error: JavaFX runtime components are missing, and are required to run this application

Which I believe is a problem with the javafx modules not being put on the module path, but on the class path (which AFAIK is not supported nowadays). That seems to be a problem with the runtime plugin being used (which says it does not support modular applications).

I was able to manually make it work by adding

runtime {
    ...
    launcher {
        jvmArgs = ["--add-modules=javafx.base,javafx.controls,javafx.fxml"]
    }
}

And then manually copying the javafx jars to the app\mods folder (which I had to create). Looking at the generated {app}.cfg file jpackage creates that's what the launcher will use as module path. I also deleted the unneeded app.classpath entries for the javafx jars from the {app}.cfg file.

Jorn Vernee
  • 31,735
  • 4
  • 76
  • 93
  • Even with Liberica and adding that line, it still doesn't seem to work for me. Same EXCEPTION_ACCESS_VIOLATION when trying to run the generated exe. – Matthew Wright Mar 07 '21 at 18:00
  • 2
    I came across something else and strangely it seems to work but not ideal to do. Copying all of the contents from `{app}\runtime\bin` into `{app}\` and then running the exe works. – Matthew Wright Mar 07 '21 at 18:04
  • Ah, ok that's good to know. Might be good to try narrow it down to the specific required files (I think it's some/all of the .dll files it needs). You should post an answer as well. – Jorn Vernee Mar 07 '21 at 18:10
  • It seems that it is enough to copy the file `{app}\runtime\bin\zip.dll` into `{app}\zip.dll` https://stackoverflow.com/a/65980258/5308944 – geh Mar 10 '21 at 13:57
  • Yeah, I looked at it with a debugger, and it's loading zip.dll from another JDK that is on the PATH on my machine, instead of from the bundled runtime image. Clearing the path makes the application crash. Looks like that particular error was fixed by: https://bugs.openjdk.java.net/browse/JDK-8254920?attachmentViewMode=list (in 16) – Jorn Vernee Mar 10 '21 at 14:53
  • @geh At least in my case, copying just zip.dll doesn't work. I haven't narrowed it down to what other dlls are necessary from that folder. Possibly relevant, my installed PATH JDK is normal Java 8. – Matthew Wright Mar 10 '21 at 19:47
  • @MatthewWright If you feel like digging into it, you could install the Windows SDK (if you don't have it already), and run the program in `windbg` to find out which library files it's actually loading (and from where). – Jorn Vernee Mar 10 '21 at 20:57
  • WinDbg is pretty cool, edited my question to include the output. – Matthew Wright Mar 11 '21 at 13:21
  • @MatthewWright Ok, so, if you apply your fix (copy everything into the app directory), do you see a .dll file which is being loaded from the app directory instead of the runtime directory? (that should be the offender) – Jorn Vernee Mar 11 '21 at 14:01
  • That worked... looks to be zip.dll and VCRUNTIME140.dll – Matthew Wright Mar 11 '21 at 14:03
  • Another note, when copying zip.dll and VCRUNTIME140.dll at least in the JavaFX example, it works with Liberica JDK 15. It does not work with AdoptOpenJDK. When copying those two dlls with AdoptOpenJdk it no longer makes an hs_err_pid but just doesn't launch. The JavaFX launches with Liberica as expected. – Matthew Wright Mar 11 '21 at 14:14
  • @MatthewWright See the second part of my answer: the problem is that the runtime plugin puts all dependencies on the class path, which is not supported with JavaFX. (See also: https://github.com/beryx/badass-runtime-plugin/issues/66) – Jorn Vernee Mar 11 '21 at 14:19
  • Trying out the Toolchains you linked in the other answer and am using these fixes for (recently released) AdoptOpenJdk 16 imageOptions/jvmArgs but get the following message trying to run the generated exe `Error occurred during initialization of boot layer java.lang.module.FindException: Module javafx.base not found` – Matthew Wright Mar 17 '21 at 21:02
2

It is a JDK15 bug. Using JPackage from JDK16 fixed the problem for me.

FlickIt
  • 71
  • 1
  • 7
  • Yes, and as @Jorn has already pointed out, it is tracked here: https://bugs.openjdk.java.net/browse/JDK-8254920 and fixed in 16 – mipa Mar 11 '21 at 12:42
  • Wanted to try it out but Gradle doesn't support JDK16 yet – Matthew Wright Mar 11 '21 at 13:31
  • @MatthewWright You can use JDK 16 and up by using the new toolchain feature (https://docs.gradle.org/6.8.3/userguide/toolchains.html) Essentially you run Gradle on JDK 15, but use JDK 16 to compile and run your code. (There's currently a bug with JDK 16 though, but there's a simple workaround for it: https://github.com/gradle/gradle/issues/15538) – Jorn Vernee Mar 11 '21 at 13:57
  • @MatthewWright you can run JPackage through command line, that is what I did. – FlickIt Mar 11 '21 at 14:33
  • Using the beryx jlink plugin to create the runtime using JDK 15.0.1 and then using the jpackager from JDK 16 from the command line using that runtime seems to be the bizarre work around that I've found to get this working. Hopefully Gradle will support JDK16 soon. – Nalyd Mar 24 '21 at 17:44
1

Combining both answers and waiting a bit for things to update fixed the issue for me.

  1. Upgraded Gradle to 7.0-RC-1 which has support for JDK 16 in gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-7.0-rc-1-bin.zip
  1. Downloaded and using Liberica JDK 16 (@FlickIt)
  2. Using the addModules() fix for Liberica in the build.gradle (@Jorn Vernee)
runtime {
    addOptions("--strip-debug", "--compress", "2", "--no-header-files", "--no-man-pages")
    addModules("javafx.base", "javafx.controls", "javafx.fxml", "javafx.graphics", "javafx.web")
}

Running jpackage in Gradle now produces a runnable JavaFX exe without needing to copy dlls!

If your application has more than just JavaFX as a dependency, change #3 to ALL-MODULE-PATH. It makes the packaged files/app much larger but will allow it to run.

runtime {
    addOptions("--strip-debug", "--compress", "2", "--no-header-files", "--no-man-pages")
    addModules("ALL-MODULE-PATH")
}
Matthew Wright
  • 1,485
  • 1
  • 14
  • 38
  • This worked for my barebones example, however when trying to migrate one of my existing JavaFX projects with this it is not working. When trying to run manually with `.\runtime\bin\java.exe -cp .\app\{app}.jar {main-class}` I get the following error message `Missing JavaFX application class {main-class}` – Matthew Wright Mar 26 '21 at 00:56
  • This appears to be due to the additional dependencies, when changing #3 to `addModules("ALL-MODULE-PATH")` the generated files are much larger but the application runs. – Matthew Wright Mar 26 '21 at 01:10