A DESCRIPTION OF THE PROBLEM :
As a followup to 8242361 I tried to load a normal webpage (https://netbeans.apache.org) with the WebEngine and observed a segfault. The segfault is reproducible and can be traced back into wrong assumptions when loading classes from native threads in the webkit integration.

The data from hs_err_pit*:
--------------- S U M M A R Y ------------

Command Line: -Djavafx.sdk.path=/home/matthias/src/jfx/build/sdk/lib eu.doppel_helix.dev.jdk.reproducecrash.TestBrowser

Host: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 16 cores, 30G, Ubuntu 20.10
Time: Wed Apr 7 18:22:15 2021 CEST elapsed time: 1 seconds (0d 0h 0m 1s)

--------------- T H R E A D ---------------

Current thread (0x00007fa400001000): JavaThread "Thread-3" daemon [_thread_in_vm, id=204072, stack(0x00007fa40b801000,0x00007fa40c000000)]

Stack: [0x00007fa40b801000,0x00007fa40c000000], sp=0x00007fa40bffe9c0, free space=8182k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x91203a] jni_CallStaticBooleanMethodV+0x7a
C [libjfxwebkit.so+0x613a55] JNIEnv_::CallStaticBooleanMethod(_jclass*, _jmethodID*, ...)+0x85
C [libjfxwebkit.so+0x2b112ad] WTF::FileSystemImpl::makeAllDirectories(WTF::String const&)+0x7d
C [libjfxwebkit.so+0x56c957] WebCore::StorageSyncManager::fullDatabaseFilename(WTF::String const&)+0x27
C [libjfxwebkit.so+0x567a8a] WebKit::StorageAreaSync::openDatabase(WebKit::StorageAreaSync::OpenDatabaseParamType)+0x3a
C [libjfxwebkit.so+0x568af9] WebKit::StorageAreaSync::performImport()+0x29
C [libjfxwebkit.so+0x56d154] WebCore::StorageThread::threadEntryPoint()+0xb4
C [libjfxwebkit.so+0x2aabb53] WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+0x63
C [libjfxwebkit.so+0x2b15f4d] WTF::wtfThreadEntryPoint(void*)+0xd


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000

Register to memory mapping:

RAX=0x0 is NULL
RBX=0x00007fa400001000 is a thread
RCX=0x00007fa40bffea98 is pointing into the stack for thread: 0x00007fa400001000
RDX=0x00007fa400001958 points into unknown readable memory: 28 3e ea 33 06 00 00 00
RSP=0x00007fa40bffe9c0 is pointing into the stack for thread: 0x00007fa400001000
RBP=0x00007fa40bffea80 is pointing into the stack for thread: 0x00007fa400001000
RSI=0x00007fa400001000 is a thread
RDI=0x00007fa400001000 is a thread
R8 =0x0000000000000001 is an unknown value
R9 =0x00007fa400001000 is a thread
R10=0x00007fa6521a3060: <offset 0x00000000013f7060> in /home/matthias/bin/jdk-11/lib/server/libjvm.so at 0x00007fa650dac000
R11=0x0000000800000820 is a pointer to class:
R12=0x0 is NULL
R13=0x0 is NULL
R14=0x00007fa40bffeb78 is pointing into the stack for thread: 0x00007fa400001000
R15=0x00007fa40bffea98 is pointing into the stack for thread: 0x00007fa400001000


Registers:
RAX=0x0000000000000000, RBX=0x00007fa400001000, RCX=0x00007fa40bffea98, RDX=0x00007fa400001958
RSP=0x00007fa40bffe9c0, RBP=0x00007fa40bffea80, RSI=0x00007fa400001000, RDI=0x00007fa400001000
R8 =0x0000000000000001, R9 =0x00007fa400001000, R10=0x00007fa6521a3060, R11=0x0000000800000820
R12=0x0000000000000000, R13=0x0000000000000000, R14=0x00007fa40bffeb78, R15=0x00007fa40bffea98
RIP=0x00007fa6516be03a, EFLAGS=0x0000000000010202, CSGSFS=0x002b000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007fa40bffe9c0)
0x00007fa40bffe9c0: 00007fa40bffea00 00007fa400001340
0x00007fa40bffe9d0: 00007fa6520ffc18 00007fa400001000
0x00007fa40bffe9e0: 00007fa400001000 0000000800001808
0x00007fa40bffe9f0: 00007fa400001000 00007fa400001950


I augemented the OpenJFX code and found the reason in modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp, #GetFileSystemClass. At that point FindClass for com.sun.webkit.FileSystem.

Together with the stacktrace above this leads to this assumption:

- webkit is initialized
- localstorage is accessed
- this causes a second native thread to spin up
- in that thread the local storage is initialized and calls back into the VM to load com.sun.webkit.FileSystem


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Sample code can be found here: https://github.com/matthiasblaesing/reproduce-openjfx-crash2/tree/7d6db9b843c17575bf03d3c18e857ad7aefa0a83 (at time of writing this that is master)

In addition to the sample code a build of OpenJFX is needed. The path to the build/sdk/lib folder needs to be set in pom.xml -> properties -> javafx.sdk.path.

After that the code can be build with "mvn package". And run with (javafx.sdk.path needs to point to build/sdk/lib folder):

java -Djavafx.sdk.path=/home/matthias/src/jfx/build/sdk/lib -cp target/reproduce-openjfx-crash2.jar eu.doppel_helix.dev.jdk.reproducecrash.TestBrowser

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
An JavaFX stage should open and the text "Done" should be shown - no crash should happen
ACTUAL -
Crash as described above.

---------- BEGIN SOURCE ----------
See steps to reproduce
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None known

FREQUENCY : always