The functions from FileSystemJava are called from different threads the root problem manifests because the JNI FindClass function behaves differently when called from a context that is the ancestor of a java frame compared to when called in isolation.
A segmentation fault is observed when local storage of a webview is accessed. At that time a new native thread is spun up and that sets up the local storage, by calling into the JVM via WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is invoked to get a referenc to the java implementation of the FileSystem. As this is is called from a new native thread (no java context available), JNI uses the system classloader to locate the class. This fails if the JavaFX modules are not on the boot module/class path. Instead on relying on fetching the class reference everytime it is needed, this change fetches it once when the JavaFX library is loaded and stores it in the WTF namespace. In addition to this it was observed, that there is no attachment to the JVM done when calling into the filesystem. No fault was observed, but the JNI specs indicate, that the JNIEnv interface is only valid when attached. ------------- Commit messages: - Address review comments - 9069811: Fix segfault when accessing local storage in webview - 9069811: Create reproducer for segfault when accessing local storage Changes: https://git.openjdk.java.net/jfx/pull/458/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=458&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264990 Stats: 362 lines in 7 files changed: 325 ins; 7 del; 30 mod Patch: https://git.openjdk.java.net/jfx/pull/458.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/458/head:pull/458 PR: https://git.openjdk.java.net/jfx/pull/458
