On Thu, 15 Apr 2021 16:43:08 GMT, Matthias Bläsing <github.com+2179736+matthiasblaes...@openjdk.org> wrote:
>> 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. > > Matthias Bläsing has updated the pull request incrementally with one > additional commit since the last revision: > > Review fix: Use correct bug id Looks good. Tested on all three platforms. I verified (on both Mac and Linux) that the new test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/458
