RFR: JDK-8334217 : [AIX] Misleading error messages after JDK-8320005 [v3]
Joachim Kern
jkern at openjdk.org
Mon Jul 1 06:08:21 UTC 2024
On Fri, 28 Jun 2024 16:42:34 GMT, Suchismith Roy <sroy at openjdk.org> wrote:
>> dll_load_library() call fails is not analyzed (the ebuf content is ignored)
>> dll_load_library does not analyze the contents of ebuf which leads to misleading error message when library loading fails.
>>
>> We now call the second dll_load_library() only if the first returns with a 'No such file or directory' error message.
>> If the first dll_load_library() found the library is not able to load it by any reason, we do not try again with a .a extension.
>> [JDK-8334217](https://bugs.openjdk.org/browse/JDK-8334217)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>
> define error string
> > Hi Suchi, what was the problem with error number? I would enrich the `dll_load_library()` interface by an eno to return the errno
>
> [#16604 (comment)](https://github.com/openjdk/jdk/pull/16604#discussion_r1494459722) This was the discussion
Yes, that's right. But my new proposal follows the points mentioned in the discussion above. A pointer to an integer is passed down to exactly the two places, where the `errno` can be examined. And before the `dlopen()` call I set `errno` to 0 and directly after I save `errno` into `eno` and give it all the way back to `os::dll_load()`. Evaluating the `errno` directly in `os::dll_load()` is to late with the explanation of the mentioned discussion.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19887#issuecomment-2199311048
More information about the hotspot-runtime-dev
mailing list