-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
native compiled image crashes when java.awt.Desktop.getDesktop is used #9138
Comments
Hello, |
graalvm-jdk-22.0.1+8.1 clone it, run ./gradlew nativeBuild, cd into the directory where the image is written to, e.g. "build/native/nativeCompile" and run ./graalvmcrash |
Hello @damnms, @fernando-valdez, I can confirm that if I do it manually: import java.awt.*;
import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
public class Application {
public static void main(String args[]) throws URISyntaxException, IOException {
Desktop.getDesktop().browse(new URI("http://localhost:8080"));
}
}
It works just fine, whereas if I use the Gradle native build mentioned in the reproducer, the resulting binary crashes. No, it's not *.so libs not being preset; they are correctly located next to the executable. I'd say this is more about Gradle native build plugin and what it does to native-image though.... |
Using agent via the gradle plugin doesn't help either.
Both the crashing and the O.K. binaries go all the way to successfully loading libawt.so. |
so should i file this then against gradle resp. org.graalvm.buildtools.native? |
@damnms @fernando-valdez The crash is caused by the fact that C code need to call to Java call on
👍 |
thanks, unfortunately it does not work on my machine.
This should be handled in client code, not on compilation time, shouldnt it? |
@damnms I ran it on CentOS 9 Stream, my laptop. Gnome on Wayland with X fallback. Gimme your exact os specs and I can replicate it. Sorry if I'm stating the obvious; if you are running a headless system, there won't be a browse action for awt... |
i am running debian trixie with xfce
its not headless ;) |
@damnms It seems that this piece fails to recognize gvfs and thus doesn't add BROWSE action capability: It seems related to having XFCE. I checked and I do have gvfs installed. I will poke around our of curiosity to see what would have to be changed for Debian or JDK to pick it up. Not a native-image issue though... |
My GVFS and GTK3 with my JDK build on my CentOS 9 Stream, GNOME desktop, when it comes to this part of code reports these supported schemes:
@damnms Debian Trixie with XFCE Desktop shows this:
Note the missing I did install various packages to get all the .so files I found with strace, e.g. Apart from sort of barebone Mandrel/Graalvm dev set:
I also installed
To no avail, the |
@damnms Uff. The package you need to install is: Case closed IMHO. |
Wow, awesome! I am sure some will benefit from this finding! 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 [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)
running debian trixie with xfce and latest graalvm, i get a crash when i try to execute Desktop.getDesktop().browse(new URI("http://localhost:8080"));
The text was updated successfully, but these errors were encountered: