8336382: Fixes error reporting in loading AWT and fonts #20169

Karm · 2024-07-13T00:18:43Z

If there is a problem with finding and calling e.g. java/awt/GraphicsEnvironment in AWTIsHeadless, the env' Exception remains set and it is not cleared. Later, that manifests as:

Fatal error reported via JNI: Could not allocate library name

Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time.

Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears JNU_NewStringPlatform calls failed, e.g.

This commit fixes the error reporting in the AWTIsHeadless.

Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g.

/tmp/JAVA_HOME/
/tmp/JAVA_HOME/conf
/tmp/JAVA_HOME/conf/fonts
/tmp/JAVA_HOME/lib

The exception is somewhat cryptic for users again, merely stating:

Exception in thread "main" java.io.IOException: Problem reading font data.
    at [email protected]/java.awt.Font.createFont0(Font.java:1205)
    at [email protected]/java.awt.Font.createFont(Font.java:1076)
    at imageio.Main.loadFonts(Main.java:139

Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing:

Exception in thread "main" java.io.IOException: Problem reading font data.
    at java.desktop@23-internal/java.awt.Font.createFont0(Font.java:1206)
    at java.desktop@23-internal/java.awt.Font.createFont(Font.java:1076)
    at imageio.Main.loadFonts(Main.java:139)
    at imageio.Main.paintRectangles(Main.java:97)
    at imageio.Main.main(Main.java:195)
    at java.base@23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
Caused by: java.lang.Error: java.home property not set
    at java.desktop@23-internal/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
    at java.desktop@23-internal/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8336382: Fixes error reporting in loading AWT and fonts (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20169/head:pull/20169
$ git checkout pull/20169

Update a local copy of the PR:
$ git checkout pull/20169
$ git pull https://git.openjdk.org/jdk.git pull/20169/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20169

View PR using the GUI difftool:
$ git pr show -t 20169

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20169.diff

Webrev

Link to Webrev Comment

If there is problem with finding and calling e.g. java/awt/GraphicsEnvironment in AWTIsHeadless, the env' Exception remains set and it not cleared. Later, that manifests as: Fatal error reported via JNI: Could not allocate library name Which is misleading. The code path is perhaps rare in normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. Instead of failing later with some clear message that indicates that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases, e.g. oracle/graal#9138 oracle/graal#8475 oracle/graal#9300 quarkusio/quarkus#31596 graalvm/mandrel#292 Karm/mandrel-integration-tests#262 This commit fixes the error reporting in the AWTIsHeadless. Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. /tmp/JAVA_HOME/ /tmp/JAVA_HOME/conf /tmp/JAVA_HOME/conf/fonts /tmp/JAVA_HOME/lib The exception is somewhat cryptic for users again, merely stating: Exception in thread "main" java.io.IOException: Problem reading font data. at [email protected]/java.awt.Font.createFont0(Font.java:1205) at [email protected]/java.awt.Font.createFont(Font.java:1076) at imageio.Main.loadFonts(Main.java:139 Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: Exception in thread "main" java.io.IOException: Problem reading font data. at java.desktop@23-internal/java.awt.Font.createFont0(Font.java:1206) at java.desktop@23-internal/java.awt.Font.createFont(Font.java:1076) at imageio.Main.loadFonts(Main.java:139) at imageio.Main.paintRectangles(Main.java:97) at imageio.Main.main(Main.java:195) at java.base@23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) Caused by: java.lang.Error: java.home property not set at java.desktop@23-internal/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180) at java.desktop@23-internal/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)

bridgekeeper · 2024-07-13T00:19:18Z

👋 Welcome back Karm! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-07-13T00:19:43Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2024-07-13T00:20:05Z

@Karm The following label will be automatically applied to this pull request:

client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2024-07-15T10:22:58Z

Webrevs

avu

Overall LGTM, please update copyright years in the changed files.

src/java.desktop/share/classes/java/awt/Font.java

prrace

There is nothing in this PR that I would accept. It should be withdrawn.

src/java.desktop/share/classes/java/awt/Font.java

src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c

Karm · 2024-07-24T12:44:46Z

Hello @prrace

TBH, I got somewhat bewildered by your comments on how this PR makes no sense. Then I realized I might have been erroneously treating the AWTIsHeadless function's contents as correct, merely building on the previous error.

If you take a look at the flow of awt_LoadLibrary.c, my problem with it is that errors originating in AWTIsHeadless are reported way later in AWT_OnLoad and that is wrong.

awt_LoadLibrary.c:

Previous fix

So I made this PR, thinking that for some headless JDK distributions it is O.K. to be entirely missing java/awt/GraphicsEnvironment class or isHeadless method.

@@ -62,15 +62,24 @@ JNIEXPORT jboolean JNICALL AWTIsHeadless() {
         graphicsEnvClass = (*env)->FindClass(env,
                                              "java/awt/GraphicsEnvironment");
         if (graphicsEnvClass == NULL) {
+            // Not finding the class is not necessarily an error.
+            if ((*env)->ExceptionCheck(env)) {
+                (*env)->ExceptionClear(env);
+            }
             return JNI_TRUE;
         }
         headlessFn = (*env)->GetStaticMethodID(env,
                                                graphicsEnvClass, "isHeadless", "()Z");
         if (headlessFn == NULL) {
+            // If we can't find the method, we assume headless mode.
+            if ((*env)->ExceptionCheck(env)) {
+                (*env)->ExceptionClear(env);
+            }
             return JNI_TRUE;
         }
         isHeadless = (*env)->CallStaticBooleanMethod(env, graphicsEnvClass,
                                                      headlessFn);
+        // If an exception occurred, we assume headless mode.
         if ((*env)->ExceptionCheck(env)) {
             (*env)->ExceptionClear(env);
             return JNI_TRUE;

New fix

The new fix I propose treats the missing class or missing method as fatal errors. The crash makes sense, the error message is correct:

$ ./target/imageio   -Djava.awt.headless=true
Fatal error reported via JNI: java/awt/GraphicsEnvironment class not found

Printing instructions (ip=0x000000000048f8d9):
...

It's a little more invasive though:

diff --git a/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c b/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
index 0fc44bfca71..7ef6dab8682 100644
--- a/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
+++ b/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
@@ -43,6 +43,12 @@
 #define VERBOSE_AWT_DEBUG
 #endif
 
+#define CHECK_EXCEPTION_FATAL(env, message) \
+    if ((*env)->ExceptionCheck(env)) { \
+        (*env)->ExceptionClear(env); \
+        (*env)->FatalError(env, message); \
+    }
+
 static void *awtHandle = NULL;
 
 typedef jint JNICALL JNI_OnLoad_type(JavaVM *vm, void *reserved);
@@ -61,25 +67,13 @@ JNIEXPORT jboolean JNICALL AWTIsHeadless() {
         env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);
         graphicsEnvClass = (*env)->FindClass(env,
                                              "java/awt/GraphicsEnvironment");
-        if (graphicsEnvClass == NULL) {
-            // Not finding the class is not necessarily an error.
-            if ((*env)->ExceptionCheck(env)) {
-                (*env)->ExceptionClear(env);
-            }
-            return JNI_TRUE;
-        }
+        CHECK_EXCEPTION_FATAL(env, "java/awt/GraphicsEnvironment class not found");
         headlessFn = (*env)->GetStaticMethodID(env,
                                                graphicsEnvClass, "isHeadless", "()Z");
-        if (headlessFn == NULL) {
-            // If we can't find the method, we assume headless mode.
-            if ((*env)->ExceptionCheck(env)) {
-                (*env)->ExceptionClear(env);
-            }
-            return JNI_TRUE;
-        }
+        CHECK_EXCEPTION_FATAL(env, "isHeadless method not found");
         isHeadless = (*env)->CallStaticBooleanMethod(env, graphicsEnvClass,
                                                      headlessFn);
-        // If an exception occurred, we assume headless mode.
+        // If an exception occurred, we assume headless mode and carry on.
         if ((*env)->ExceptionCheck(env)) {
             (*env)->ExceptionClear(env);
             return JNI_TRUE;
@@ -88,12 +82,6 @@ JNIEXPORT jboolean JNICALL AWTIsHeadless() {
     return isHeadless;
 }
 
-#define CHECK_EXCEPTION_FATAL(env, message) \
-    if ((*env)->ExceptionCheck(env)) { \
-        (*env)->ExceptionClear(env); \
-        (*env)->FatalError(env, message); \
-    }
-
 /*
  * Pathnames to the various awt toolkits
  */

Thanks for your time. I hope the PR makes more sense now or at least that I managed to get my point across.

If you think there is a better way to handle it, tell me and I'll do it. I don't dwell on a particular implementation, I merely want the misleading error gone.

Thx
K.

theRealAph · 2024-08-19T14:34:20Z

There is nothing in this PR that I would accept. It should be withdrawn.

I think we're all finding it a bit hard to understand what to do.

Is the problem that

This is not a bug?
This is not a bug that should be fixed?
The fix is wrong?
There is a much better way to fix it?
This is an enhancement, but it is not a worthwhile one?

Please, help us here.

theRealAph · 2024-08-19T14:35:56Z

P.S. There surely is an actual problem here: the error message that is currently output misrepresents the actual cause of the failure.

Karm · 2024-09-13T09:02:07Z

ping @prrace

jerboaa · 2024-09-23T13:17:09Z

@Karm There are a few things that have not yet been addressed:

@avu mentioned here that copyright years of the file need updating
There is a title mismatch between this PR and the JBS entry. Which one should it be if any? (and I'll help you fix that one).

I'd also merge in latest master since x86 tests have since been disabled. That should fix the GHA issue.

Thanks!

… java.homenot set and AWT cannot try to lookup fonts

…s-fonts_backup

Karm · 2024-09-28T23:07:39Z

Hello @jerboaa,

@avu mentioned here that copyright years of the file need updating

The year there is 2024 for both edited files.

There is a title mismatch between this PR and the JBS entry. Which one should it be if any? (and I'll help you fix that one).

Use the title from this PR, please.

I'd also merge in latest master since x86 tests have since been disabled. That should fix the GHA issue.

Done.

Karm · 2024-09-28T23:10:53Z

Font.java and information leakage

@prrace @jerboaa

Would this solution address the concern? Instead of passing on the whole throwable, we just inspect it and if it is this particular one, we pass on the information to the user?

+++ b/src/java.desktop/share/classes/java/awt/Font.java
@@ -971,6 +971,9 @@ public static Font[] createFonts(InputStream fontStream)
             }
             return createFont0(fontFormat, fontStream, true, tracker);
         } catch (InterruptedException e) {
+            if (e.getCause().getMessage().contains("java.home property not set")) {
+                throw new IOException("Problem reading font data. java.home property not set.");
+            }
             throw new IOException("Problem reading font data.");

Karm · 2024-09-29T21:04:54Z

Font.java and information leakage

@prrace @jerboaa

Would this solution address the concern? Instead of passing on the whole throwable, we just inspect it and if it is this particular one, we pass on the information to the user?

+++ b/src/java.desktop/share/classes/java/awt/Font.java
@@ -971,6 +971,9 @@ public static Font[] createFonts(InputStream fontStream)
             }
             return createFont0(fontFormat, fontStream, true, tracker);
         } catch (InterruptedException e) {
+            if (e.getCause().getMessage().contains("java.home property not set")) {
+                throw new IOException("Problem reading font data. java.home property not set.");
+            }
             throw new IOException("Problem reading font data.");

I retract this. It's not that inconvenient and I don't want to complicate this PR.

jerboaa · 2024-09-30T09:06:10Z

There is a title mismatch between this PR and the JBS entry. Which one should it be if any? (and I'll help you fix that one).

Use the title from this PR, please.

Done.

Karm · 2024-10-03T11:40:29Z

@prrace I added a test that triggers the described issue.

Unpatched awt_LoadLibrary.c

$ TIME=`date +%s`;mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTr
eport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/;
Test results: passed: 14; failed: 1
...
Output and diagnostic info for process 578718 was saved into 'pid-578718-output.log'
----------System.err:(38/2940)----------
 stdout: [Transforming java.awt.GraphicsEnvironment.
isHeadless removed from java.awt.GraphicsEnvironment.
FATAL ERROR in native method: Could not allocate library name
        at jdk.internal.loader.NativeLibraries.load(java.base@24-internal/Native Method)
        at jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(java.base@24-internal/NativeLibraries.java:331)
...
test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'FATAL ERROR in native method: isHeadless method not found' missing from stdout/stderr

Patched awt_LoadLibrary.c

$ TIME=`date +%s`;mkdir -p test.${TIME}/jdk/JTwork test.${TIME}/jdk/JTreport; jtreg -a -ignore:quiet -w:test.${TIME}/jdk/JTwork -r:test.${TIME}/jdk/JTreport -jdk:/home/karm/workspaceRH/jdk/build/linux-x86_64-server-release/images/graal-builder-jdk/ /home/karm/workspaceRH/jdk/test/jdk/java/awt/Headless/;
Test results: passed: 15

Karm · 2024-10-11T16:33:09Z

Hello @mrserb, could you take a look, please?

mrserb · 2024-10-18T19:49:07Z

src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c

-        if (graphicsEnvClass == NULL) {
-            return JNI_TRUE;
-        }
+        CHECK_EXCEPTION_FATAL(env, "java/awt/GraphicsEnvironment class not found");


Taking out any discussion about graal/etc as well as absent of any classes and methods, I agree that the current code is questionable.

But the solution to always print "java/awt/GraphicsEnvironment class not found" does not seems to be correct as well.

One of the problem with this code is an actual conflict between two patches. Both are related to warning caused by pending java exceptions, but implemented differently:

https://bugs.openjdk.org/browse/JDK-8031001: treated the java exceptions as a fatal errors and fail fast

https://bugs.openjdk.org/browse/JDK-8130507: ignores the java exceptions and tried to fallback into the headless mode in assumption that it may be fine for the application

Both of that patches only changes the code paths which were reported by "some tools"/checkjni - this is the reason why the next code was not reported and was not patched(which is wrong):

graphicsEnvClass = (*env)->FindClass(env, "java/awt/GraphicsEnvironment"); if (graphicsEnvClass == NULL) { return JNI_TRUE; } headlessFn = (*env)->GetStaticMethodID(env, graphicsEnvClass, "isHeadless", "()Z"); if (headlessFn == NULL) { return JNI_TRUE; }

If we would like to follow JDK-8031001 approach we should use fatal error here and fail fast, for example if OOM is occurred.
If we would like to follow JDK-8130507 we should clear an exceptions and try to use headless mode.

I guess ignoring an exceptions is not that good and the fix for JDK-8130507 should be rethinking.

You can change the CHECK_EXCEPTION_FATAL macro to something like

#define CHECK_EXCEPTION_FATAL(env, message) \ if ((*env)->ExceptionCheck(env)) { \ (*env)->ExceptionDescribe(env); (*env)->FatalError(env, message); \ }

In this case the root cause of the bug will always be printed.
And then update the fatal message to some generic text.

Note that the FatalError is used in this code since we always should load the library(libawt_xawt or libawt_headless) or fail fast, otherwise we most probably will get an error later.

Thank you @mrserb for your time. Let me amend the PR and run tests again.

openjdk bot added the client [email protected] label Jul 13, 2024

Karm changed the title ~~Fixes error reporting in loading AWT and fonts~~ 8336382: Fixes error reporting in loading AWT and fonts Jul 15, 2024

openjdk bot added the rfr Pull request is ready for review label Jul 15, 2024

Karm mentioned this pull request Jul 15, 2024

native-image-agent ceased to work as expected with AWT/JNI oracle/graal#9300

Closed

avu suggested changes Jul 15, 2024

View reviewed changes

src/java.desktop/share/classes/java/awt/Font.java Outdated Show resolved Hide resolved

prrace suggested changes Jul 15, 2024

View reviewed changes

src/java.desktop/share/classes/java/awt/Font.java Outdated Show resolved Hide resolved

src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c Outdated Show resolved Hide resolved

src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c Show resolved Hide resolved

Karm added 2 commits July 24, 2024 13:59

Reverts changes to java/awt/Font.java

49c6ebd

Treats missing class as a fatal error

4e33725

Karm requested a review from prrace July 24, 2024 12:46

Karm added 3 commits September 29, 2024 00:56

Display "Problem reading font data. java.home property not set." when…

091f5ae

… java.homenot set and AWT cannot try to lookup fonts

Merge branch 'master' of github.com:openjdk/jdk into awt-load-message…

8b203e7

…s-fonts_backup

Year 2024 for Font.java

0cd0ab4

Reverting "java.home property not set" from Font.java

2b3de58

Reverting changes from Font.java

aa47484

Adds test for awt_LoadLibrary.c's AWTIsHeadless

c206f93

Amends test description

bba9a3c

Karm requested a review from avu October 3, 2024 12:31

mrserb reviewed Oct 18, 2024

View reviewed changes

Karm mentioned this pull request Oct 24, 2024

[native-image] Adds -H:+ForeignAPISupport for all GraalVM 24.2+ quarkusio/quarkus#44092

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8336382: Fixes error reporting in loading AWT and fonts #20169

8336382: Fixes error reporting in loading AWT and fonts #20169

Karm commented Jul 13, 2024 •

edited by openjdk bot

Loading

bridgekeeper bot commented Jul 13, 2024

openjdk bot commented Jul 13, 2024

openjdk bot commented Jul 13, 2024

mlbridge bot commented Jul 15, 2024 •

edited

Loading

avu left a comment

prrace left a comment

Karm commented Jul 24, 2024

theRealAph commented Aug 19, 2024

theRealAph commented Aug 19, 2024

Karm commented Sep 13, 2024

jerboaa commented Sep 23, 2024 •

edited

Loading

Karm commented Sep 28, 2024

Karm commented Sep 28, 2024

Karm commented Sep 29, 2024

Font.java and information leakage

jerboaa commented Sep 30, 2024

Karm commented Oct 3, 2024 •

edited

Loading

Karm commented Oct 11, 2024

mrserb Oct 18, 2024 •

edited

Loading

mrserb Oct 23, 2024 •

edited

Loading

Karm Oct 24, 2024

8336382: Fixes error reporting in loading AWT and fonts #20169

Are you sure you want to change the base?

8336382: Fixes error reporting in loading AWT and fonts #20169

Conversation

Karm commented Jul 13, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewing

Webrev

bridgekeeper bot commented Jul 13, 2024

openjdk bot commented Jul 13, 2024

openjdk bot commented Jul 13, 2024

mlbridge bot commented Jul 15, 2024 • edited Loading

Webrevs

avu left a comment

Choose a reason for hiding this comment

prrace left a comment

Choose a reason for hiding this comment

Karm commented Jul 24, 2024

Previous fix

New fix

theRealAph commented Aug 19, 2024

theRealAph commented Aug 19, 2024

Karm commented Sep 13, 2024

jerboaa commented Sep 23, 2024 • edited Loading

Karm commented Sep 28, 2024

Karm commented Sep 28, 2024

Font.java and information leakage

Karm commented Sep 29, 2024

Font.java and information leakage

jerboaa commented Sep 30, 2024

Karm commented Oct 3, 2024 • edited Loading

Unpatched awt_LoadLibrary.c

Patched awt_LoadLibrary.c

Karm commented Oct 11, 2024

mrserb Oct 18, 2024 • edited Loading

Choose a reason for hiding this comment

mrserb Oct 23, 2024 • edited Loading

Choose a reason for hiding this comment

Karm Oct 24, 2024

Choose a reason for hiding this comment

Karm commented Jul 13, 2024 •

edited by openjdk bot

Loading

mlbridge bot commented Jul 15, 2024 •

edited

Loading

jerboaa commented Sep 23, 2024 •

edited

Loading

Karm commented Oct 3, 2024 •

edited

Loading

mrserb Oct 18, 2024 •

edited

Loading

mrserb Oct 23, 2024 •

edited

Loading