[24.1] imageio AWT tests fail with JDK 23 ea #262
Comments
|
/cc @Karm |
jerboaa
changed the title
|
The test also fails on JDK 24 based Mandrel, fwiw: |
|
Taking a look now... |
|
During the build, any specific way you are getting around this Vendor Version glitch in launcher? before I dive into those scripts of ours? Both master+JDK24 and 24.1+JDK23: i.e. it bakes in the error output: |
|
I am sorry, I have a mixup in JDK versions I think. Mandrel 24.1 + JDK 23 build works for me on amd64: ....but the same job fails on aarch64: No need to stress I haven't changed anything in the way Adoptium API is queried, I'm not downloading musl versions.... |
|
@Karm See graalvm/mandrel-packaging#429. For I haven't seen the error that you see on aarch64, though (don't have such hardware handy). |
|
For 24.1: You might have to downgrade build JDK version. |
|
@jerboaa Both master + JDK 24 ea and 24.1 + JDK 23 ea builds work fine for me on Windows, Linux amd64 and Mac aarch64 now. The only weird quirk is Linux aarch64 with 24.1+JDK 23 ea, captured here: graalvm/mandrel#766 |
|
Thanks! |
|
@jerboaa We have again the problem with loading awt so libs, I am looking deeper into it. And putting on TODO to modify this so as the error check happens sooner and makes sense in awt_LoadLibrary.c The error happened before that, so the exception text is populated with "Could not allocate library name" but the NewString went just fine. The error was earlier and the message is misleading. |
As in the "visibility hidden" problem to be fixed in OpenJDK? |
|
It's not that it seems :-/ Wip.. |
|
@jerboaa @zakkak When I manually babysit it and prepare correct jni-config.json by hand AND prepare fake JAVA_HOME as we had to do in Quarkus AND if I force the headless property on the executable at runtime, it works: So it seems like I will try to collect notes and prepare some more coherent report. |
|
Thanks! |
|
Upstream issue: oracle/graal#9300 |
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 java.desktop@22.0.1/java.awt.Font.createFont0(Font.java:1205)
at java.desktop@22.0.1/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)
|
@Karm Any update on this? The upstream graalvm issue I see is solved. Yet, we still see builds failing for example here: #266 (comment) |
|
Lemme check if it got integrated properly. |
|
@jerboaa It is broken again, i.e. Mandrel upstream build number 1430 worked, 1466 is broken. I'll take a look later today as to exactly why and whether it is a new issue or a regression of what was previously fixed. |
|
@jerboaa So, the timeline is that oracle/graal@71e6492 worked (as I note in the comment). Git bisect tells me that this is the first commit that broke it: oracle/graal@fa89c6bf1ba6 |
@Karm Do you have links to those builds?
@Karm Do we need to backport oracle/graal@71e6492 to the 24.1 branch in order to fix imageio for that release? Something else? Let's close this issue only when JDK 23 mandrel and JDK 24 mandrel are both fixed. Thanks! |
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 java.desktop@22.0.1/java.awt.Font.createFont0(Font.java:1205)
at java.desktop@22.0.1/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)
The imageio AWT integration tests seem to fail a JDK 23-based Mandrel 24.1 build with:
Steps to reproduce
The text was updated successfully, but these errors were encountered: