RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

Yumin Qi minqi at openjdk.java.net
Tue Jan 25 05:06:39 UTC 2022


On Tue, 25 Jan 2022 01:59:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> * The jimage code was using the OS code (dlopen/loadlibrary etc) to try and load the zip library when needed.
Yes. The zip library has to be in PATH.
> * The VM, which is always loaded first, always used to load the zip library unconditionally, hence the OS would simply return the JVM's zip handle to the jimage code.
Yes. After the fix, jimage will use the version that JVM is using.
> * When we changed the VM to only load the zip library if needed (not realizing jimage may also need it) then the jimage code would now only succeed if the zip library was in the appropriate lookup paths for the OS.
Yes. When in JVM, zip library was always loaded (before https://bugs.openjdk.java.net/browse/JDK-8237750) so jimage in fact get the loaded zip handle from JVM. Unless user set PATH(other than jdk(jre)\bin) to contain the "zip.dll | libzip.so | libzip.dylib" then jimage will load and use that version. After this fix, jimage will use the same version as jvm. 
> * The fix is to change the jimage code so that it asks the JVM for the zip library, as the JVM is always setup correctly to find it.
Yes.

Thanks for taking a detail look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7206


More information about the core-libs-dev mailing list