On Sat, 10 Apr 2021 15:01:08 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> I'm currently rerunning tests and preparing and update - further analysis >> showed, that thread attachment is handled in >> `WebCore::StorageThread::threadEntryPoint()`: >> >> https://github.com/openjdk/jfx/blob/808b1078f762a923bd5e74298daffeb88ed108c2/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp#L76-L87 >> >> The analysis was triggered by a request from @neilcsmith-net on the netbeans >> mailing list. He pointed out, that the fault should have happened earlier if >> the the thread indeed was not attached. In that case `GetEnv` is required >> to return `NULL`. From the >> [doc](https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#getenv): >> >>> If the current thread is not attached to the VM, sets *env to NULL, and >>> returns JNI_EDETACHED. If the specified version is not supported, sets *env >>> to NULL, and returns JNI_EVERSION. Otherwise, sets *env to the appropriate >>> interface, and returns JNI_OK. > > That's good since it will simplify the fix to the root cause, which is that > looking up the class fails depending on the ClassLoader used to load the > JavaFX modules. I understand the crash would be at a different point, but it would still be a crash, I think? That is, if the method handlers are correctly registered via the OnLoad function, and later a new native thread tries to access a function that is not yet attached, that will still crash, I believe. (at least, the GetEnv will return NULL and that result is used later). So while the 2 issues are not related, I think there are really 2 issues. ------------- PR: https://git.openjdk.java.net/jfx/pull/458
