WebView crashes with some websites

[dukescript]

WebView crashes with JDK 11.0.1 on Windows and OS X in a Maven project when trying to load http://html5test.com/ or https://openjfx.io/. (Works fine for loading https://google.com)

Observed behaviour:
The website loads and I can see the content building up for 1 or 2 seconds. Then the application crashes

How ro reproduce:
try to load http://html5test.com/ or https://openjfx.io/

public class HelloFX extends Application {

    @Override
    public void start(Stage stage) {
        WebView webView = new WebView();
        webView.getEngine().load("http://html5test.com/");
  //      webView.getEngine().load("https://openjfx.io/");
        Scene scene = new Scene(new StackPane(webView), 640, 480);
        stage.setScene(scene);
        stage.show();
    }

    public static void main(String[] args) {
        launch();
    }

}

I attached a maven project with the test code.

java11-webview-crash.zip

[muralibilla]

@dukescript I tested with latest code in windows 7 and i could not reproduce the crash for both sites http://html5test.com/, https://openjfx.io/.

[dukescript]

I'm running Windows 10, and I can reproduce it every time. Can I provide any more information to help reproducing it?
I can also reproduce it on Mac OS X High Sierra every time ( I tested html5test.com there). On Windows there's no output, but on OS X there is. I'll collect this data and add it here.

[eppleton]

On a mac I get this:

cd /Users/antonepple/Documents/Projekte/JavaFXTrainingZuerich/javafx; JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home M2_HOME=/Applications/apache-maven-3.3.1 /Applications/apache-maven-3.3.1/bin/mvn exec:java
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building demo 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ hellofx ---
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000001061ec58b, pid=33651, tid=118791
#
# JRE version: Java(TM) SE Runtime Environment (11.0.1+13) (build 11.0.1+13-LTS)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.1+13-LTS, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x3ec58b]  jni_CallStaticBooleanMethodV+0xe2
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/antonepple/Documents/Projekte/JavaFXTrainingZuerich/javafx/hs_err_pid33651.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Abort trap: 6

hs_err_pid33651.log

[jperedadnr]

I can reproduce the issue on Mac (High Sierra), running the Maven project, even with JavaFX 11.0.1 and OpenJDK 11.0.1:

[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ hellofx ---
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010e3ea8f3, pid=21421, tid=128771
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x3ea8f3]  jni_CallStaticBooleanMethodV+0xe2

However, it works fine if I run from command line (java --module-path ...), or if I run the HelloFX class from a Gradle project.

[dukescript]

Thanks @jperedadnr for testing and for the workaround.

[dukescript]

After feedback here I checked why only Maven failed: I started from NetBeans, which by default uses "exec:java". After changing this to "exec:exec" it works fine.

[mokun]

Why is webview unable to load even a simple github page ?

It cannot render any github issue pages or wiki pages correctly and ironically not even this very page at we are reading.

Is there workaround ?

[SatGarcia]

I'm running into this issue on my Macs (one High Sierra and one Mojave). I'm testing in my own project (not the basic HelloFX) but the supposed fix with changing exec:java to exec:java does not work (or even make sense). I can load https://www.google.com just fine, but any github URL causes WebView to crash.

[kevinrushforth]

I'm testing in my own project (not the basic HelloFX) but the supposed fix with changing exec:java to exec:java does not work (or even make sense). I can load https://www.google.com just fine, but any github URL causes WebView to crash.

Please file a new bug with enough information to reproduce it. At least we need a test case along with your system info. If you can provide the hs_err*.log file that would be helpful.

I am closing this bug, since the original problem was resolved, and was not a JavaFX problem.

[SatGarcia]

I just tried the exact same setup as @dukescript and got the exact same error, except NetBeans wasn't used at all. I just compiled via "mvn compile exec:java" and the program segfaults. Here's the message I get:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000001027ea8f3, pid=50703, tid=127747
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x3ea8f3]  jni_CallStaticBooleanMethodV+0xe2
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

I don't think this warrants a separate issue because it is exactly the same problem as the original and the proposed fix (changing something in netbeans) doesn't apply here. I'm fine creating a separate one if you want though.

[SatGarcia]

To be clear: I just tried the hellofx example from the openjfx/samples repository, but with the HelloFX class modified to match that of the original post.

[kevinrushforth]

OK, I'll reopen it then.

[kevinrushforth]

This has all the hallmarks of a mismatch between the native jfxwebkit.so file and the Java class files. Can you run it with java -Djavafx.verbose=true ?

[SatGarcia]

I get this additional output when I run with the -Djavafx.verbose=true param.

WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libprism_es2.dylib
Loaded library /libprism_es2.dylib from resource
JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libglass.dylib
Loaded library /libglass.dylib from resource
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libjfxwebkit.dylib
Loaded library /libjfxwebkit.dylib from resource
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libjavafx_font.dylib
Loaded library /libjavafx_font.dylib from resource
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libglib-lite.dylib
Loaded library /libglib-lite.dylib from resource
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libgstreamer-lite.dylib
Loaded library /libgstreamer-lite.dylib from resource
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libjfxmedia.dylib
Unpacked library /libfxplugins.dylib from resource
Unpacked library /libglib-lite.dylib from resource
Unpacked library /libjfxmedia_avf.dylib from resource
Loaded library /libjfxmedia.dylib from resource
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libjfxmedia_avf.dylib
Loaded library /libjfxmedia_avf.dylib from resource
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: /Users/sat/.m2/repository/org/openjfx/javafx-graphics/11.0.1/libjfxmedia_qtkit.dylib

[kevinrushforth]

Loaded library /libjfxwebkit.dylib from resource

That will load libjfxwebkit.dylib from your cache directory, which by default is:

$HOME/.openjfx/cache/11.0.1

You might check the time stamp on that file and see if it is up to date. Other than that, I can't think of anything obvious.

[votingsystem]

I can reproduce this error on Debian Buster

hs_err_pid20034.log

[johanvos]

Am I correct that this only occurs when you are using mvn and exec:java ?

[SatGarcia]

@johanvos That is correct. I was able to get it to work without crashing when starting via the java command instead of using mvn exec:java. I ran it both ways (mvn and straight java command) with the javafx.verbose=true. Looks like mvn is looking for dylib files in the m2 repository but that only contains jar files (which themselves contain the dylib files). It then falls back to using the cache referred to by @kevinrushforth. Java just uses the dylibs in the lib directory in the openjfx sdk.

[johanvos]

I can reproduce this error on Debian Buster

hs_err_pid20034.log

This seems to load libjfxwebkit.so from this location:
/usr/lib/x86_64-linux-gnu/jni/libjfxwebkit.so

Any idea on how it got there?

[johanvos]

@johanvos That is correct. I was able to get it to work without crashing when starting via the java command instead of using mvn exec:java. I ran it both ways (mvn and straight java command) with the javafx.verbose=true. Looks like mvn is looking for dylib files in the m2 repository but that only contains jar files (which themselves contain the dylib files). It then falls back to using the cache referred to by @kevinrushforth. Java just uses the dylibs in the lib directory in the openjfx sdk.

The order of searching is a bit more complex, and described in https://github.com/javafxports/openjdk-jfx/blob/develop/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java

First, loadLibraryFullPath is called. If that doesn't retrieve the library, the java.library.path is searched. If that fails, the resources are checked, and the library will be cached.
Hence, if java.library.path contains libjfxwebkit.dylib from another install, that library will be picked and that typically lead to the mismatch described above.

[johanvos]

I can now reproduce this on linux.
It only occurs when using maven with exec:java. In that case, there is no new process started, but maven uses some wrapper:
java -classpath ... org.codehaus.plexus.classworlds.launcher.Launcher

In this case, the webkit library is loaded from the resources, but it is exactly the same as the version in the javafx sdk. Also, using gradle, or using mvn with a separate Java process, there is no problem.
Hence, the issue seems unrelated to the location of the webkit native library.

The crash occurs here:

V  [libjvm.so+0x9006aa]  jni_CallStaticBooleanMethodV+0x7a
C  [libjfxwebkit.so+0x54b801]  JNIEnv_::CallStaticBooleanMethod(_jclass*, _jmethodID*, ...)+0x81
C  [libjfxwebkit.so+0x1567329]  WebCore::FileSystem::makeAllDirectories(WTF::String const&)+0x79

That can be due to sending null as one of the parameters to callStaticBooleanMethod

The function calling this is:

bool makeAllDirectories(const String& path)
{
    JNIEnv* env = WebCore_GetJavaEnv();

    static jmethodID mid = env->GetStaticMethodID(
            GetFileSystemClass(env),
            "fwkMakeAllDirectories",
            "(Ljava/lang/String;)Z");
    ASSERT(mid);

    jboolean result = env->CallStaticBooleanMethod(
            GetFileSystemClass(env),
            mid,
            (jstring)path.toJavaString(env));
...
}

(where GetFileSystemClass should return com.sun.webkit.FileSystem)

[johanvos]

I've traced it down to GetFileSystemClass(env) and mid being null. (why is the ASSERT(mid) not triggered?)

This is code that is called in WebCore/platform/java/FileSystemJava.cpp:

    static jmethodID mid = env->GetStaticMethodID(
            GetFileSystemClass(env),
            "fwkMakeAllDirectories",
            "(Ljava/lang/String;)Z");
    ASSERT(mid);
fprintf(stderr, "[JVDBG] makeAllDirectories, native, mid = %p\n", mid);
fprintf(stderr, "[JVDBG] makeAllDirectories, native, fsc = %p\n", GetFileSystemClass(env));

the FileSystemClass is obtained as follows:

static jclass GetFileSystemClass(JNIEnv* env)
{
    static JGClass clazz(env->FindClass("com/sun/webkit/FileSystem"));
    ASSERT(clazz);
    return clazz;
}

When running an application the way it should be (e.g. java -p /path/to/modules --add-modules javafx.web...) this works fine, the FileSystem class is obtained and the method is obtained, e.g.

[JVDBG] makeAllDirectories, native, mid = 0x7f2cc8524db0
[JVDBG] makeAllDirectories, native, fsc = 0x7f2cc8397c78

When running from the maven launcher command (java -classpath ... org.codehaus.plexus.classworlds.launcher.Launcher ) this gives the following output:

[JVDBG] makeAllDirectories, native, mid = (nil)
[JVDBG] makeAllDirectories, native, fsc = (nil)

Clearly, this leads to a crash in the VM when invoking that (nil) method.

Hence, when using the maven java launcher, the code in webkit can not access com.sun.webkit.FileSystem

Using the maven java launcher fails. That is not a bug in JavaFX. We can make the error more elegant, by checking on the FileSystem class being null, and if so throwing a Java Exception (instead of a VM crash). But there are many places where this happens, and we should be careful not to decrease performance.

[darmbrust]

Loaded library /libjfxwebkit.dylib from resource

That will load libjfxwebkit.dylib from your cache directory, which by default is:

$HOME/.openjfx/cache/11.0.1

You might check the time stamp on that file and see if it is up to date. Other than that, I can't think of anything obvious.

This cache folder and how it is handled causes other issues as well, with compatibility with maven. Not sure if it is related to the library loading issues here, but I think it really should be rethought. I didn't look closely, but also didn't notice any handling for multiple JVMs trying to run JavaFX apps at the same time - and the file collisions that could happen in creating or locking that cache location on different platforms.

https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-January/023010.html

This will also cause problems with tomcat style containers, which use classloader isolation - we can now no longer start JavaFX in headless mode to use the tasks APIs, etc, without doing hackery like I have below.

To me, each JVM that tries to start a JavaFX instance should be writing to its own folder in tmp, not in an arbitrary cache folder.

I've currently been using this hack, to make each maven plugin that tries to start a JavaFX process use its own file path:

                      String s = System.getProperty("javafxHack");
                      int i = 0;
                      if (!StringUtils.isBlank(s))
                      {
                         i = Integer.parseInt(s);
                         i++;
                      }
                      System.setProperty("javafxHack", i + "");
                      System.setProperty("javafx.version", "mavenHack" + i);

Fragile as that is... This was not a problem we had in JDK 8. It is one of many stumbles I've had trying to migrate to JDK 11.

[johanvos]

To me, each JVM that tries to start a JavaFX instance should be writing to its own folder in tmp, not in an arbitrary cache folder.

That is already possible, by setting the javafx.cachedir property. See
https://github.com/javafxports/openjdk-jfx/blob/develop/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L225

By default, we don't do that as in most cases you don't want to reinstall the libraries all the time. But with that property, you have full control over where the native libraries are cached.

[SatGarcia]

There was some mention of using mvn exec:exec to run the program without the crashing issue discussed here. Could someone elaborate more on how that would work for the hellofx example?

[jperedadnr]

See issue openjfx/openjfx-docs#76, basically you will need to add the same --module-path and --add-modules arguments as you were running the java command.

[arunvc]

Yes webview crashes
javafx-11.0.2, openjdk 11.0.1 2018-10-16, Ubuntu 18.04 (build 11.0.1+13-Ubuntu-3ubuntu118.04ppa1)

[shannah]

I get the same thing running on Mac OS 10.14.5, Open JDK 11

Here is the crash report

hs_err_pid96474.log

I'm using a custom classloader that tries to detect JavaFX, and if not present, it loads it from a predefined folder. I do this so that the app works on both JDKs that included JavaFX, and ones that do not.

[kevinrushforth]

The crash is due to a mismatch between the Java modules and the native libraries, which are getting pulled from the wrong location. Since this is a configuration / setup issue, I am closing this.

[nemphys]

The crash is due to a mismatch between the Java modules and the native libraries, which are getting pulled from the wrong location. Since this is a configuration / setup issue, I am closing this.

This is not the issue (at least in my case) and I think this should be re-opened.

I am using update4j to load JavaFX dynamically in the modulepath using the maven-built JavaFX jars. Even if I use the Gluon JavaFX SDK, which has the native libs separated from the javafx jars, I get exactly the same crash ("jni_CallStaticBooleanMethodV+0x84"), even though the native libs are clearly loaded from the correct locations (verified by the output of -Djavafx.verbose).

EDIT:

Using the maven java launcher fails. That is not a bug in JavaFX. We can make the error more elegant, by checking on the FileSystem class being null, and if so throwing a Java Exception (instead of a VM crash). But there are many places where this happens, and we should be careful not to decrease performance.

Since this is not a JavaFX bug, can you please point out were the bug originates from?

[micheljung]

Update

Ok, I saw you created update4j/update4j#83
Why on earth didn't I look there first

---

I'm facing the same problem as @nemphys (were you able to solve it?). I don't get an hs_err_pid file, not even if I explicitly specify -XX:ErrorFile. Thanks to -Djavafx.verbose=true I get at least:

WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\MyUser\git\update4j-javafx-crash\bootstrap\build\app\bin\api-ms-win-core-console-l1-1-0.dll
Loaded library /api-ms-win-core-console-l1-1-0.dll from resource

But as explained by @johanvos, that's not an issue (you get the same messages when starting it successfully without update4j)

@nemphys I'm highly suspect it has something to do with class/module loaders since that seems to be the only difference.