RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call
David Holmes
dholmes at openjdk.java.net
Tue Jan 25 02:03:36 UTC 2022
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:
> Please review,
> When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result.
> The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle.
>
> Tests: tier1,4,7 in test
> Manually tested user case, and checked output of jimage list <modules> for jlinked files using --compress=2.
>
> Thanks
> Yumin
Hi Yumin,
So let me see if I have this clear.
- The jimage code was using the OS code (dlopen/loadlibrary etc) to try and load the zip library when needed.
- 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.
- 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.
- 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.
Does that sum it up?
Thanks.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7206
More information about the core-libs-dev
mailing list