FastR internal error: java.lang.NullPointerException

[epragtbeamtree]

FastR internal error: java.lang.NullPointerException

[Akirathan]

Hello @epragtbeamtree, thanks for the report.

How did you produce the helloworldr binary?

I was able to reproduce the issue on Ubuntu 20.04, with the latest Graal master, with:

$GRAALVM_HOME/bin/javac HelloWorldR.java
$GRAALVM_HOME/bin/native-image --language:R HelloWorldR helloworldr
env R_HOME=$GRAALVM_HOME/languages/R ./helloworldr

From the generatedfastr_errors.log, I can see that there is some problem with fetching home from llvm, more specifically, LLVMLanguage.getLLVMLanguageHome() (which is transitively called from RContext.initialize) returns null. I don't know yet where is this issue stemming from. Let me investigate and get back to you.

Moreover, why are you setting java.awt.headless property in the static constructor? For native-image, java.awt.GraphicsEnvironment.isHeadless() should always return true, because, as far as I know, AWT is not yet supported in native images. Do you think this issue is related to the AWT library, or were you just trying some stuff?

[epragtbeamtree]

Hi @Akirathan ,

Thanks for your quick feedback. I created the image using the following:

native-image --language:R -Djava.awt.headless=true --no-fallback HelloWorldR

I'm setting the java.awt.headless property because if I don't, the application doesn't start at all as a native-image, and fails with the following error:

 bin  ./helloworldr                                               ✔ │ 3m 34s │ base  │ graalvm64-17.0.3 
Starting...
In R context
Exception in thread "main" org.graalvm.polyglot.PolyglotException: java.lang.UnsatisfiedLinkError: no awt in java.library.path
	at com.oracle.svm.core.jdk.NativeLibrarySupport.loadLibraryRelative(NativeLibrarySupport.java:132)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:47)
	at java.lang.Runtime.loadLibrary0(Runtime.java:818)
	at java.lang.System.loadLibrary(System.java:1989)
	at sun.awt.PlatformGraphicsInfo.lambda$static$0(PlatformGraphicsInfo.java:38)
	at java.security.AccessController.executePrivileged(AccessController.java:169)
	at java.security.AccessController.doPrivileged(AccessController.java:318)
	at sun.awt.PlatformGraphicsInfo.<clinit>(PlatformGraphicsInfo.java:37)
	at java.awt.GraphicsEnvironment.lambda$getHeadlessProperty$0(GraphicsEnvironment.java:150)
	at java.security.AccessController.executePrivileged(AccessController.java:169)
	at java.security.AccessController.doPrivileged(AccessController.java:318)
	at java.awt.GraphicsEnvironment.getHeadlessProperty(GraphicsEnvironment.java:145)
	at java.awt.GraphicsEnvironment.isHeadless(GraphicsEnvironment.java:122)
	at com.oracle.truffle.r.runtime.ROptions.applyDefaults(ROptions.java:213)
	at com.oracle.truffle.r.runtime.ROptions$ContextStateImpl.initialize(ROptions.java:125)
	at com.oracle.truffle.r.runtime.context.RContext.doEnvOptionsProfileInitialization(RContext.java:607)
	at com.oracle.truffle.r.runtime.context.RContext.initializeContext(RContext.java:558)
	at com.oracle.truffle.r.runtime.context.TruffleRLanguage.initializeContext(TruffleRLanguage.java:127)
	at com.oracle.truffle.r.runtime.context.TruffleRLanguage.initializeContext(TruffleRLanguage.java:61)
	at com.oracle.truffle.api.TruffleLanguage$Env.postInit(TruffleLanguage.java:3390)
	at com.oracle.truffle.api.LanguageAccessor$LanguageImpl.postInitEnv(LanguageAccessor.java:281)
	at com.oracle.truffle.polyglot.PolyglotLanguageContext.ensureInitialized(PolyglotLanguageContext.java:685)
	at com.oracle.truffle.polyglot.PolyglotContextImpl.eval(PolyglotContextImpl.java:1324)
	at com.oracle.truffle.polyglot.PolyglotContextDispatch.eval(PolyglotContextDispatch.java:63)
	at org.graalvm.polyglot.Context.eval(Context.java:399)
	at org.graalvm.polyglot.Context.eval(Context.java:425)
	at HelloWorldR.main(HelloWorldR.java:20)
Caused by: Attached Guest Language Frames (0)
Internal GraalVM error, please report at https://github.com/oracle/graal/issues/.

[Akirathan]

I'm setting the java.awt.headless property because if I don't, the application doesn't start at all as a native-image, and fails with the following error:

Seems related to MacOS-specific issue in hpi-swa/trufflesqueak#168. On Ubuntu 20.04, I don't have to specify java.awt.headless property. Anyway, this is unrelated to this issue.

Our problem is with providing correct home directories for Truffle languages. The issue is with configuration - just run native image build with:

$GRAALVM_HOME/bin/native-image --language:R -Dorg.graalvm.launcher.home=$GRAALVM_HOME HelloWorldR

and everything works as expected.

For more info, see https://github.com/oracle/graal/blob/master/sdk/src/org.graalvm.home/src/org/graalvm/home/impl/DefaultHomeFinder.java

[Akirathan]

I am closing this issue now as it is unrelated to FastR.

[epragtbeamtree]

@Akirathan Thanks for looking into this.

Would it be helpful to give a bit more information than just the NPE? I'm happy to help in that, but is there a way how I can run with debug or verbose information to see where exactly the NPE occured?

[steve-s]

Truffle team is planning to work on documenting and improving this experience (setting language home for native images with some languages embedded) in general.

It is good point that TruffleLanguage#getLanguageHome() may instead of returning null throw some nice exception. Its JavaDoc does not document what happens when the language home is not available. CC @jchalou

[jchalou]

@steve-s @epragtbeamtree @Akirathan I am not sure how the issue is related to the LLVM's language home, because what fixed it was setting the org.graalvm.launcher.home property which is not setting the LLVM language home returned by LLVMLanguage.getLLVMLanguageHome(). I also haven't found a place where returning null from TruffleLanguage#getLanguageHome() would cause a NPE, but maybe I am missing something.

[Akirathan]

@jchalou - LLVMLanguage#getLLVMLanguageHome transitively calls into com.oracle.truffle.polyglot.LanguageCache#getLanguageHomeImpl, which checks "org.graalvm.language.llvm.home" property, which was set by DefaultHomeFinder according to the provided "org.graalvm.launcher.home" property during native image build time.

So, if org.graalvm.launcher.home is not set during the native image build time, LLVMLanguage#getLLVMLanguageHome returns null, which later causes NPE in com.oracle.truffle.llvm.runtime.ToolchainImpl.getToolPath - you can see that in this stacktrace: fastr_errors.log.

TL:DR; NPE is thrown not directly in TruffleLanguage#getLanguageHome(), but later in FastR. More specifically, when loading the base package and trying to figure out LLVM toolchain path (as can be seen in the attached stack trace). I guess that what @steve-s was trying to say is whether it makes sense for TruffleLanguage#getLanguageHome() to return null, and whether throwing some custom exception in case the home is missing wouldn't be better? If returning null from TruffleLanguage#getLanguageHome() makes sense, then we will handle such case in fastr. It is possible that null home is problematic only for fastr, and not yet for any other truffle language.

[jchalou]

Ok, I missed that DefaultHomeFinder sets the language homes from launcher home during native image build time. I will discuss this internally in the team whether we can improve anything. Thanks.

[jchalou]

We do not plan to change the functionality at the moment. It is up to the languages to react properly to the situation where TruffleLanguage#getLanguageHome returns null. In this case the LLVM language needs an improvement. However, we will improve the embedding documentation here: https://www.graalvm.org/22.1/reference-manual/embed-languages/#build-native-executables-from-polyglot-applications to mention language homes.