RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3]

Thomas Stuefe stuefe at openjdk.org
Sat Aug 6 11:40:06 UTC 2022


On Sat, 6 Aug 2022 11:14:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.base/share/native/libjli/emessages.h line 111:
>> 
>>> 109: #define DLL_ERROR2      "Error: failed %s, because %s"
>>> 110: #define DLL_ERROR3      "Error: could not find executable %s"
>>> 111: #define DLL_ERROR4      "Error: Failed to load %s"
>> 
>> Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases.
>
> The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path:
> 
> static JLI_List expandArgFile(const char *arg) {
>     JLI_List rv;
>     struct stat st;
>     FILE *fptr = fopen(arg, "r");
> 
>     /* arg file cannot be opened */
>     if (fptr == NULL || fstat(fileno(fptr), &st) != 0) {
>         JLI_ReportMessage(CFG_ERROR6, arg);
>         exit(1);
>     } else {
>         if (st.st_size > MAX_ARGF_SIZE) {
>             JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE);
>             exit(1);
>         }
>     }
> 
>     rv = readArgFile(fptr);
> 
>     /* error occurred reading the file */
>     if (rv == NULL) {
>         JLI_ReportMessage(DLL_ERROR4, arg);
>         exit(1);
>     }
>     fclose(fptr);
> 
>     return rv;
> }
> 
> 
> In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used

You also have one use where the VM does a GetProcAddress on windows. "Failed to load" feels wrong for a failed dlsym. But "Error loading" is not much better either, I admit.

In general, the smaller and focused you keep changes, the easier they are to review and the better they are down-portable if that should be needed. I usually try to do aesthetic changes in separate RFEs. In this change, if you want to fix the display of additional diagnostic info, I'd just do that.

-------------

PR: https://git.openjdk.org/jdk/pull/9749


More information about the core-libs-dev mailing list