Application always crashes on start

[xeruf]

hs_err_pid11473.log

Using OpenJDK 11 on Linux. I have already tried deleting the user dir. This always happened for OpenJFX 11 and 12.

For OpenJFX 13 I get an error but no crash report:

17:09.749 I [JavaFX Applicat] WidgetManager - Registering WidgetFactory EmptyWidget Empty class sp.it.pl.layout.widget.EmptyWidget
17:09.752 I [JavaFX Applicat] WidgetManager - Registering TemplateFactory Playback + Playlist
17:09.779 I [JavaFX Applicat] WidgetManager - Widget=ImageViewer factory update, source files available=true class files available=true
17:09.850 I [JavaFX Applicat] WidgetManager - Registering WidgetFactory ImageViewer Image Viewer class imageViewer.ImageViewer
17:09.855 I [JavaFX Applicat] WidgetManager - Widget=AppLauncher factory update, source files available=true class files available=true
Exception in Application start method
17:09.867 I [JavaFX Applicat] App - Stopping application
17:09.935 I [JavaFX Applicat] Hotkeys - Stopping global hotkeys

> Task :run FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':run'.
> Process 'command '/usr/lib/jvm/java-11-openjdk-amd64/bin/java'' finished with non-zero exit value 1

[sghpjuikit]

1 Why is there no stacktrace

I think this happens because the runTry { } no longer catches all exceptions. As per:

   if (e is VirtualMachineError || e is ThreadDeath || e is InterruptedException || e is LinkageError) throw e

This is intended as fatal exceptions should not be caught. I am not sure if not doing this would allow us to log this error.

We may consider replacing runTry {} with try {} catch, for app start, but I dislike the idea. This is an opportunity to know for good though. Can you please remove that line (its in a Try.kt runTry()) and see if the output is logged properly?

2 Nature of error

Anyway, this is a weird error as I would expect fatal error to (always) crash JVM, but it appears to not be the case. I know, because the log shows the application gracefuly shuting down.

Which makes me question what makes an error fatal one. The implementation of runTry that ignores certain errors mirrors exactly implementation of Try in scala. I suspect the implementation is not viable for all contexts.

3 Log

Nonetheless, the log you provided gives us:

j  com.sun.glass.ui.gtk.GtkWindow._setIcon(JLcom/sun/glass/ui/Pixels;)V+0
j  com.sun.glass.ui.Window.setIcon(Lcom/sun/glass/ui/Pixels;)V+13
j  com.sun.javafx.tk.quantum.WindowStage.setIcons(Ljava/util/List;)V+224
j  javafx.stage.Stage.doVisibleChanged(Z)V+146
j  javafx.stage.Stage.access$100(Ljavafx/stage/Stage;Z)V+2
j  javafx.stage.Stage$1.doVisibleChanged(Ljavafx/stage/Window;Z)V+5
j  com.sun.javafx.stage.StageHelper.visibleChangedImpl(Ljavafx/stage/Window;Z)V+11
j  com.sun.javafx.stage.WindowHelper.visibleChanged(Ljavafx/stage/Window;Z)V+6
j  javafx.stage.Window$12.invalidated()V+640
J 3229 c1 javafx.beans.property.BooleanPropertyBase.set(Z)V (76 bytes) @ 0x00007fcde500133c [0x00007fcde5000ba0+0x000000000000079c]
j  javafx.stage.Window.setShowing(Z)V+11
j  javafx.stage.Window.show()V+2
j  javafx.stage.Stage.show()V+1
j  sp.it.pl.gui.objects.window.stage.WindowBase.show()V+4
j  sp.it.pl.gui.objects.window.stage.WindowManager.createWindow(Z)Lsp/it/pl/gui/objects/window/stage/Window;+51
j  sp.it.pl.gui.objects.window.stage.WindowManager.deserialize()V+314
j  sp.it.pl.main.App.start(Ljavafx/stage/Stage;)V+100

so App.start() -> createWindow() -> show() -> setVisible() -> setIcon() -> native exception

4 Troubleshooting: Please see WindowManager.create() and remove the line w.stage.icons setTo windowIcons to not use any icons and see if that helps.

This may be caused by several issues:

• your application location is set to wrong value, causing resources not being found, causing this exception: pls print the App.location object to make sure it points to the project/app directory
• bug in JavaFX on Linux
• incompatibility between JavaFX13 and JDK11. Please try JavaFX12 and post any errors that you enounter.

[xeruf]

incompatibility between JavaFX13 and JDK11. Please try JavaFX12 and post any errors that you enounter.

Please read my post again. These are two separate errors, occurring on separate versions.

[sghpjuikit]

These are two separate errors

Which means the error when using OpenJFX13 may be due to incompatibility with JDK11. It is more likely to be an OpenJFX bug.

[sghpjuikit]

If you want to progress with this, I need you to try the workarounds and post the error logs, best for both OpenJFX13 and OpenJFX12.

We may revert to 12 easily, but not to 11.

[xeruf]

Right, I forgot. But I understand the point. Will do tomorrow.

[sghpjuikit]

Np, just wanted to avoid deadlock.

[xeruf]

tried 1 and 4, to no avail yet

[sghpjuikit]

I dont understand what happens when you use OpenJFX12. You said the behavior is different. We do not need 13, so we can focus on 12, but you did not mention how, other than 'This always happened for OpenJFX 11 and 12.' which is almost a contradiction.

[xeruf]

The JVM crash happened for 11 and 12, the application error for 13.

[sghpjuikit]

Ah I see, the order of provided logs confused me. You can reproduce the JVM crash with OpenJFX and same stacktrace? I'll be trying to reproduce this again, but I have little hope I'll manage on Windows and I have no idea how to launch this on Linux...

[sghpjuikit]

@Xerus2000 pls try the latest build and tell me if the issue persists. I may have fixed it.

Long story: this is a cursed issue.

I changed JDK to 11, but the org.gradle.java.home property had no effect. I did fix some error and after that I was able to run JDK11 + OpenJFX13 with no problems.

I removed jdk link just in case, but fell into a linkJdk bug in case link does not exist.

I fixed that and made sure linkJdk generates link to jdk11, but this had no effect because IDE overrides the settings when the application runs.

I manually set IDE to use JDK11 and reproduced -some- application crash.

I traced the problem to unhandled widget class version exception in ClassLoader.loadClass when widget is compiled into higher version as supported as is loaded. This is undocumented exception, which made me ignore it.

I fixed the issue using Try when ClassLoader is created and also loadClass() invoked, but ran into fatal exception check issue.

The actual error is UnsupportedClassVersionError, which is LinkageError, which Try considers fatal exception, which it probably is, in all but single case - ours - when custom class loaders are used, but runTry always re-throws it. So I re-caught it.

The application now handles widget class loading properly (no crashes), logs any possible error and even goes so far as to attempt recompiling widgets automatically if class version problem is detected.

[sghpjuikit]

I dropped JDK11 support. I will migrate to 13 when I solve the issue with kotlinc not supporting 13 as a target.

Please see https://adoptopenjdk.net/ for recommended JDK. Both Hotspot and J9 are supported.