On Fri, 9 Apr 2021 20:32:10 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> @kevinrushforth @johanvos thank you both for review/checking. I pushed an >> update, that addresses the comments and updated the issue with the final >> issue id. I did not touch the comments on the original commits, so that >> history is kept intact (I understand, that skara bot will use the PR message >> as base for the final squashed commit and ignores the individual commits) > >> I pushed an update, that addresses the comments and updated the issue with >> the final issue id. > > You also need to adjust the PR title to match the bug title exactly. > >> I did not touch the comments on the original commits, so that history is >> kept intact (I understand, that skara bot will use the PR message as base >> for the final squashed commit and ignores the individual commits) > > Yes, this is correct. And we prefer contributors to do just what you did for > incremental changes. Thanks. 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. ------------- PR: https://git.openjdk.java.net/jfx/pull/458
