ImageIO AWT Quarkus IT test fails with GraalVM 23.0.0-dev build after AWT change #31596
Comments
|
Seems related to: oracle/graal#4921. The native image build produces The native image build produces these artefacts: It would appear that those |
|
Thx @jerboaa , I'll process it. |
jerboaa
changed the title
|
Failure seen with JDK 17-based Graal master as well. Updated the summary. |
|
I'm running with mandrel-java17-23.0.0-dev6da6520d012-2023-03-14 and mandrel-java20-23.0.0-dev6da6520d012-2023-03-14 to see now. |
|
O.K., well, I will gather the libs in target next to the executable, amend Dockerfile.native and QuickStart. It might make some things clearer. It's not like we hadn't had to shuffle libraries around or install additional ones before, we did: e.g. Dockerfile.native or Dockerfile.native-micro |
|
Note: It doesn't seem easily configurable on the GraalVM's side atm: |
|
Gonna test on Windows too now :) |
|
I've got the files in place, according the |
|
I can see that The file not only exists: (updated Quarkus NativeImageBuildStep put it there) but it's also intact: (neither SELinux nor permissions issue, I tried disabling the former and changing |
|
FWIW, I cannot get a simple swing app to work either. No quarkus involved: But the trace looks suspicious. It seems the JDK wants to load the library which fails. Strace indicates only |
|
@jerboaa I know my dl is looking at the right file, but it returns null or at least GraalVM native integration thinks so: dlhandle = PosixUtils.dlopen(canonicalIdentifier, Dlfcn.RTLD_LAZY());
System.out.printf("KARM: RTLD_LAZY Status is not null: %s of %s.\n", dlhandle.isNonNull(), canonicalIdentifier);Hmm. |
So, the handle is either NULL or gdb o'clock... |
|
Using |
|
e.g. Full log: https://karms.biz/pastebin/dlopen-awt-q-full.txt Beginning in |
|
When we fix Temurin OpenJDK based Mandrel to correctly load awt libs at runtime: or use either a LabsJDK based Mandrel or GraalVM CE distro, we also need to fix what we do in the AWT extension itself WRT initializing the state:
144 CHECK_EXCEPTION_FATAL(env, "Could not allocate font manager name");
145
146 if (fmanager && fmProp) {
147 JNU_CallStaticMethodByName(env, NULL, "java/lang/System", "setProperty",
148 "(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;",
149 fmProp, fmanager);
>>> 150 CHECK_EXCEPTION_FATAL(env, "Could not allocate set properties");
151 }Hmm. Deferring Full log: To get Quarkus up to this point, one needs the diff --git a/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildStep.java b/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildStep.java
index 396e3adf003..12b4d9c7573 100644
--- a/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildStep.java
+++ b/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildStep.java
@@ -5,6 +5,7 @@
import java.io.IOException;
import java.io.UncheckedIOException;
import java.nio.charset.StandardCharsets;
+import java.nio.file.DirectoryStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
@@ -265,6 +266,24 @@ public NativeImageBuildItem build(NativeConfig nativeConfig, LocalesBuildTimeCon
Files.delete(generatedSymbols);
}
}
+
+ // See https://github.com/oracle/graal/issues/4921
+ try (DirectoryStream<Path> sharedLibs = Files.newDirectoryStream(outputDir, "*.{so,dll}")) {
+ sharedLibs.forEach(src -> {
+ Path dst = null;
+ try {
+ dst = Path.of(outputTargetBuildItem.getOutputDirectory().toAbsolutePath().toString(),
+ src.getFileName().toString());
+ log.debugf("Copying a shared lib from %s to %s.", src, dst);
+ Files.copy(src, dst, StandardCopyOption.REPLACE_EXISTING);
+ } catch (IOException e) {
+ log.errorf("Could not copy shared lib from %s to %s. Continuing. Error: %s", src, dst, e);
+ }
+ });
+ } catch (IOException e) {
+ log.errorf("Could not list files in directory %s. Continuing. Error: %s", outputDir, e);
+ }
+
System.setProperty("native.image.path", finalExecutablePath.toAbsolutePath().toString());
return new NativeImageBuildItem(finalExecutablePath, |
|
I'd need to access |
|
O.K., I'll enhance |
|
is a false alarm. There is nothing wrong with The error state originates way earlier, over here: https://github.com/openjdk/jdk17u-dev/blob/jdk-17.0.7+5/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L62 And is not cleared. I'll open a PR to enhance that part with a call to Adding to the JNI Config then solves this particular part. |
|
I've got it finally working. The last thing to clear is this exception: The image gets generated just fine, but obviously, something is wrong in there. I will dive in and check it. |
|
I have the Monitor fixed. The I'll run the full TS now and polish the PR.... |
|
/me Currently on LUTs/colour profiles where something is still off, i.e. there are still some test images that could take down the app. |
|
Both HotSpot and Native correctly fill 2 profiles here: Although at this place, profiles[0] is null in Native: : ( |
|
It's gonna be something in the lazy liblcms.so init. |
|
Resolved. *.pf colour profile files needed to be included. The JDK code is just hiding this failure as it has never dealt with the situation that not even the handful of default, JDK-baked in profiles weren't present. |
|
Any idea how to make this work with Jib builder? Should this be another issue? |
Karm
added a commit
to Karm/jdk
that referenced
this issue
Jul 13, 2024
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)
3 tasks
Karm
added a commit
to Karm/jdk
that referenced
this issue
Nov 26, 2024
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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The
awtintegration testio.quarkus.awt.it.ImageDecodersIT.testComplexImagesfails like so:Expected behavior
Test passes.
Actual behavior
Test fails.
How to Reproduce?
Run the
awtintegration-test with a JDK 20-based GraalVM master build. Eg. from here:Output of
uname -aorverNo response
Output of
java -version20+36GraalVM version (if different from Java)
master
Quarkus version or git rev
main
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
Might be related to oracle/graal#6088 that got merged recently.
The text was updated successfully, but these errors were encountered: