Chinese characters in path to java.exe caused "Unable to load native library" error

[himawari-san]

Platform &:Architecture:
Windows10.0.18362
OpenJDK11U-jre_x64_windows_hotspot_11.0.6_10.zip
OpenJDK11U-jre_x86-32_windows_hotspot_11.0.6_10.zip

Steps to reproduce the issue:

1. Download the JRE described above from https://adoptopenjdk.net/releases.html
2. Unzip it.
3. Rename "jdk-11.0.6+10-jre" to "jdk漢字含む" ("漢字含む" are 4 Chinese characters)
4. Execute java.exe as follows:

$ jdk漢字含む\bin\java -version
Error occurred during initialization of VM
Unable to load native library:

$ ren jdk漢字含む jdk
$ jdk\bin\java -version
openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)

jdk-11.0.5+10-jre didn't caused the error.
Thanks for your binaries.

[ThibautSF]

Looks like to be the same with Korean characters

Reported by a user on my app, jlink build with jdk-11.0.6+10

The launch script in the picture

@echo off
set DIR="%~dp0"
set JAVA_EXEC="%DIR:"=%\java"
%JAVA_EXEC%  -p "%~dp0/../app" -m com.pmm.ParadoxosGameModManager/com.pmm.ParadoxosGameModManager.ModManager  %*

Edit: Also tested with 11.0.5, confirm it works

[karianna]

@himawari-san Can you try the 11.0.6 from adoptopenjdk.net/upstream.html please?

[himawari-san]

@karianna I got the same error.
Thanks for your support.

[YaSuenag]

I think it is a bug in upstream. I confirmed this issue on current jdk/jdk source. It would occur on any path which contains CJK character(s).

I can fix it with the patch as below, so I want to send review request for hotspot-runtime-dev in OpenJDK. Have you ever worked for it to OpenJDK community? If not so, I will file it to JBS.

diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
--- a/src/hotspot/os/windows/os_windows.cpp
+++ b/src/hotspot/os/windows/os_windows.cpp
@@ -4207,14 +4207,16 @@
     size_t prefix_len = wcslen(prefix);
     size_t full_path_size = is_abs ? 1 + buf_len : JVM_MAXPATHLEN;
     size_t result_size = prefix_len + full_path_size - prefix_off;
-    result = (wchar_t*) os::malloc(sizeof(wchar_t) * (additional_space + result_size), mtInternal);
+    size_t result_buffer_size = sizeof(wchar_t) * (additional_space + result_size);
+    result = (wchar_t*) os::malloc(result_buffer_size, mtInternal);

     if (result == NULL) {
       err = ENOMEM;
     } else {
-      size_t converted_chars;
+      ZeroMemory(result, result_buffer_size);
       wchar_t* path_start = result + prefix_len - prefix_off;
-      err = ::mbstowcs_s(&converted_chars, path_start, buf_len + 1, buf, buf_len);
+      int win32_ret = MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, buf, (int)buf_len, path_start, (int)(buf_len + 1));
+      err = (win32_ret == 0) ? EINVAL : ERROR_SUCCESS;

       if ((err == ERROR_SUCCESS) && needs_fullpath) {
         wchar_t* tmp = (wchar_t*) os::malloc(sizeof(wchar_t) * full_path_size, mtInternal);

[himawari-san]

@YaSuenag No, I haven't. I appreciated your help.

[YaSuenag]

I reported this issue to JBS, and sent review request to hotspot-runtime-dev.

https://bugs.openjdk.java.net/browse/JDK-8240197
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-February/038330.html

[himawari-san]

@YaSuenag thank you for your contribution!
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html

[YaSuenag]

I fixed this issue in jdk/jdk, and also backported to jdk/jdk11u-dev. It will be shipped in 11.0.8 . I guess you can use AdoptOpenJDK 11 on CJK path since 11.0.8 .