On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga <ysuen...@openjdk.org> wrote:
> I got garbled exception message as following when I run `livenmethods` CLHSDB > command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???????W > > My Windows laptop is set Japanese Locale, garbled message was written in > Japanese. > saproc.dll would throw exception via > [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) > JNI function, but it accepts UTF-8 encoded message. However > [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) > Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can > convert localized (non ascii) chars to UTF-8 string. I use them in this PR > and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been > already > deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) > - it does not seem to add to any other executables. There are probably 25 or so places in our code where we use FormatMessage to get the error message. Are these all going to run into the same FormateMessage bug? Also, it's not clear to me why you are getting garbled text in the first place. You said "Windows API might not return UTF-8 encoded string on Japanese locale." Why is that the case? src/jdk.hotspot.agent/share/native/libsaproc/sadis.c line 75: > 73: > 74: #ifdef _WINDOWS > 75: static int getLastErrorString(char *buf, size_t len) Is this being removed because a copy already exists in jni_util_md.c, and you now have access to this copy because you are linking against java.dll? ------------- PR: https://git.openjdk.java.net/jdk/pull/1928
