On Wed, 8 Mar 2023 23:23:33 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> This patch modifies the `getLastErrorString` method to return a `jstring`.
>> Thanks to that we can avoid unnecessary back and forth conversions between
>> Unicode and other charsets on Windows.
>>
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks
>> `errno`. I verified all uses of the method and confirmed that `errno` is not
>> used anywhere.
>> - While at it, I found and fixed a few calls to
>> `JNU_ThrowIOExceptionWithLastError` that were done in context where
>> `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and
>> `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to
>> have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones.
>> The generated messages were not observed anywhere, because they were
>> replaced by a static message in ZIP_Open, which is the only method used by
>> other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>>
>> Tier1-3 tests continue to pass.
>>
>> No new automated regression test; testing this requires installing a
>> language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows
>> 11, selecting Chinese language, then checking if the message on exception
>> thrown by `InetAddress.getByName("nonexistent.local");` starts with
>> `"不知道这样的主机。"` (or
>> `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the
>> change, the exception message started with a row of question marks.
>
> We don't have a test for the SA changes you made. The best way to test it is
> with clhsdb. Run the following against a JVM pid:
>
> `$ jhsdb clhsdb --pid <pid>`
>
> Use "jstack -v" to get a native pc from a frame, and then try `disassemble`
> on the address. It most likely will produce an exception since it can't find
> hsdis, which is actually what we want to be testing in this case:
>
>
> hsdb> disassemble 0x00007f38b371fca0
> Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot
> open shared object file: No such file or directory
>
>
> You'll need to test separately on Windows and any unix platform.
Thanks @plummercj for the instructions. Here's the results:
Linux, with this change applied:
hsdb> disassemble 0x00007f3484558da0
Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open
shared object file: No such file or directory
Windows, EN, with the change:
hsdb> disassemble 0x00000107d4dae0c6
Error: sun.jvm.hotspot.debugger.DebuggerException: The specified module could
not be found
Windows, misconfigured CN, without the change:
hsdb> disassemble 0x00000200d60de0b4
Error: sun.jvm.hotspot.debugger.DebuggerException: ?????????
Windows, misconfigured CN, with the change:
hsdb> disassemble 0x000001fab996e0b4
Error: sun.jvm.hotspot.debugger.DebuggerException: 找不到指定的模块。
(note: I had to run `chcp 65001` in the console, otherwise the exception would
still display incorrectly)
-------------
PR: https://git.openjdk.org/jdk/pull/12922
