RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call
Yumin Qi
minqi at openjdk.java.net
Fri Jan 28 17:47:08 UTC 2022
On Wed, 26 Jan 2022 08:59:49 GMT, Alan Bateman <alanb 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
>
> I think this looks okay but I think @JimLaskey and/or @sundararajana should look at this because it creates a dependency on a JVM_* function. I'm trying to think if there are any interop issues when using jrtfs. Jim/Sundar can correct me but I think we are okay there because a tool on say JDK 8 (or 11 or 17) that accesses a JDK 19 run-time image will use the BasicImageReader and won't use libjimage in the target VM.
Thanks to @AlanBateman, @JimLaskey or @sundararajana Could you have a look and comment?
Thanks.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7206
More information about the core-libs-dev
mailing list