On Wed, 12 Oct 2022 17:43:47 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
> Isn't it an illustration of a more general problem we have with native code > where it can mess with FP environment at any time? > > We already have similar problems with MXCSR register and provide verification > logic (part of `-Xcheck:jni`) to catch modifications and support conditional > restoration of MXCSR register on x86_64. x86_32 validates x87 control word > when `-Xcheck:jni` is enabled. > > Should we do something similar here instead? I tend to agree. As others have observed, a `dlopen` call (or something with same nefarious behavior) could also happen inside JNI code. But I think the interesting (and perhaps surprising) part here is that, from the perspective of the developer, no native code has executed - only a library has been loaded (via `System::loadLibrary`). Note also that this specific problem is triggered by `dlopen` itself, because certain libraries might have some "bad" (from the perspective of JVM) initialization code. But since we're talking about JNI, JNI_OnLoad is another potential source of problem, as its native code is executed as soon as the library is loaded (and that, too, can leave the JVM in a bad state). ------------- PR: https://git.openjdk.org/jdk/pull/10661
