NullPointerException: Cannot invoke "com.oracle.truffle.api.nodes.DirectCallNode.call(Object[])" because "this.callNode" is null

[arouel]

We run multiple times a week into the following error when executing the Gradle task configClassesGatherImports:

> Task :load:configClassesGatherImports FAILED
gradle/actions: Writing build results to /runnertmp/_work/_temp/.gradle-actions/build-results/__github-actions-shared-1773737705533.json


FAILURE: Build failed with an exception.

[Incubating] Problems report is available at: file:///runnertmp/_work/steampipe/steampipe/build/reports/problems/problems-report.html
* What went wrong:
16 actionable tasks: 9 executed, 7 from cache
Execution failed for task ':load:configClassesGatherImports'.
> An unexpected error has occurred. Would you mind filing a bug report?
  Cmd+Double-click the link below to open an issue.
  Please copy and paste the entire error output into the issue's description.
  
  https://github.com/apple/pkl/issues/new


java.lang.NullPointerException%3A%20Cannot%20invoke%20%22com.oracle.truffle.api.nodes.DirectCallNode.call%28Object%5B%5D%29%22%20because%20%22this.callNode%22%20is%20null
  
  –– Pkl Error ––
  Cannot invoke "com.oracle.truffle.api.nodes.DirectCallNode.call(Object[])" because "this.callNode" is null
  
  106 | renderer =
        ^^^^^^^^
  at pkl.base#Module.output.renderer (https://github.com/apple/pkl/blob/0.31.0/stdlib/base.pkl#L106)
  
  131 | if (renderer is ValueRenderer)
            ^^^^^^^^
  at pkl.base#Module.output.text (https://github.com/apple/pkl/blob/0.31.0/stdlib/base.pkl#L131)
  
  Pkl 0.31.0 (Linux 6.12.66-88.122.amzn2023.aarch64, Java 25.0.2)
  
  java.lang.NullPointerException: Cannot invoke "com.oracle.truffle.api.nodes.DirectCallNode.call(Object[])" because "this.callNode" is null
  	at org.pkl.core.ast.expression.binary.LetExprNode.executeGeneric(LetExprNode.java:73)
  	at org.pkl.core.ast.member.TypeCheckedPropertyNode.evalTypedObjectCached(TypeCheckedPropertyNode.java:54)
  	at org.pkl.core.ast.member.TypeCheckedPropertyNodeGen.executeImpl(TypeCheckedPropertyNodeGen.java:76)
  	at org.pkl.core.ast.PklRootNode.execute(PklRootNode.java:46)
  	at com.oracle.truffle.api.impl.DefaultCallTarget.call(DefaultCallTarget.java:118)
  	at com.oracle.truffle.api.impl.DefaultIndirectCallNode.call(DefaultIndirectCallNode.java:53)
  	at org.pkl.core.ast.expression.member.ReadSuperPropertyNode.executeGeneric(ReadSuperPropertyNode.java:67)
  	at org.pkl.core.ast.expression.literal.PropertiesLiteralNodeGen.executeGeneric(PropertiesLiteralNodeGen.java:239)
  	at org.pkl.core.ast.member.TypeCheckedPropertyNode.evalTypedObjectCached(TypeCheckedPropertyNode.java:54)
  	at org.pkl.core.ast.member.TypeCheckedPropertyNodeGen.executeAndSpecialize(TypeCheckedPropertyNodeGen.java:133)
  	at org.pkl.core.ast.member.TypeCheckedPropertyNodeGen.executeImpl(TypeCheckedPropertyNodeGen.java:98)
  	at org.pkl.core.ast.PklRootNode.execute(PklRootNode.java:46)
  	at com.oracle.truffle.api.impl.DefaultCallTarget.call(DefaultCallTarget.java:118)
  	at com.oracle.truffle.api.impl.DefaultIndirectCallNode.call(DefaultIndirectCallNode.java:53)
  	at org.pkl.core.runtime.VmUtils.doReadMember(VmUtils.java:358)
  	at org.pkl.core.runtime.VmUtils.readMemberOrNull(VmUtils.java:287)
  	at org.pkl.core.ast.expression.member.ReadPropertyNode.evalObject(ReadPropertyNode.java:75)
  	at org.pkl.core.ast.expression.member.ReadPropertyNodeGen.executeAndSpecialize(ReadPropertyNodeGen.java:125)
  	at org.pkl.core.ast.expression.member.ReadPropertyNodeGen.executeGeneric(ReadPropertyNodeGen.java:93)
  	at org.pkl.core.ast.expression.primary.ResolveVariableNode.executeGeneric(ResolveVariableNode.java:83)
  	at org.pkl.core.ast.type.TypeTestNode.executeBoolean(TypeTestNode.java:58)
  	at org.pkl.core.ast.expression.ternary.IfElseNode.evaluateCondition(IfElseNode.java:54)
  	at org.pkl.core.ast.expression.ternary.IfElseNode.executeGeneric(IfElseNode.java:47)
  	at org.pkl.core.ast.member.TypeCheckedPropertyNode.evalTypedObjectCached(TypeCheckedPropertyNode.java:54)
  	at org.pkl.core.ast.member.TypeCheckedPropertyNodeGen.executeImpl(TypeCheckedPropertyNodeGen.java:76)
  	at org.pkl.core.ast.PklRootNode.execute(PklRootNode.java:46)
  	at com.oracle.truffle.api.impl.DefaultCallTarget.call(DefaultCallTarget.java:97)
  	at com.oracle.truffle.api.nodes.IndirectCallNode$1.call(IndirectCallNode.java:96)
  	at org.pkl.core.runtime.VmUtils.doReadMember(VmUtils.java:358)
  	at org.pkl.core.runtime.VmUtils.readMemberOrNull(VmUtils.java:287)
  	at org.pkl.core.runtime.VmUtils.readMemberOrNull(VmUtils.java:250)
  	at org.pkl.core.runtime.VmUtils.readMember(VmUtils.java:230)
  	at org.pkl.core.runtime.VmUtils.readTextProperty(VmUtils.java:173)
  	at org.pkl.core.EvaluatorImpl.lambda$evaluateOutputText$3(EvaluatorImpl.java:151)
  	at org.pkl.core.EvaluatorImpl.lambda$doEvaluate$18(EvaluatorImpl.java:422)
  	at org.pkl.core.EvaluatorImpl.doEvaluate(EvaluatorImpl.java:367)
  	at org.pkl.core.EvaluatorImpl.doEvaluate(EvaluatorImpl.java:418)
  	at org.pkl.core.EvaluatorImpl.evaluateOutputText(EvaluatorImpl.java:147)
  	at org.pkl.cli.CliImportAnalyzer.render(CliImportAnalyzer.kt:74)
  	at org.pkl.cli.CliImportAnalyzer.doRun(CliImportAnalyzer.kt:33)
  	at org.pkl.commons.cli.CliCommand.run(CliCommand.kt:48)
  	at org.pkl.gradle.task.AnalyzeImportsTask.doRunTask(AnalyzeImportsTask.java:50)
  	at org.pkl.gradle.task.BasePklTask.withFallbackTruffleRuntime(BasePklTask.java:167)
  	at org.pkl.gradle.task.ModulesTask.runTask(ModulesTask.java:136)
  	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
  	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
  	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)

We observe the error since we use version 0.28.0 but it is still present in the most recent release 0.31.0.

When re-executing the Gradle task it typically succeeds.

Gradle Configuration

pkl {
    javaCodeGenerators {
        register("configClasses") {
            addGeneratedAnnotation = true
            val pklFiles = fileTree("src/main/resources") { include("AppConfig.pkl") }
            sourceModules.set(pklFiles)
            generateJavadoc.set(true)
        }
        register("testConfigClasses") {
            addGeneratedAnnotation = true
            val pklFiles = fileTree("src/test/resources") { include("*.pkl") }
            sourceModules.set(pklFiles)
            sourceSet = sourceSets.test
        }
    }
}

[StefMa]

I guess it make sense to provide a bit more information. Seems like you're using the Gradle plugin? 🤔 Can you share your config as well as what gradle task you execute?

[arouel]

@StefMa I updated the description to keep the details in one place.

[HT154]

Thanks for the additional info about this.

I think this is related to a known race condition related to concurrent stdlib initialization.

[odenix]

Here is what I found so far:

• Many (but not all) stdlib modules are static singletons shared across evaluators. This avoids repeated parsing and repeated Truffle node construction and makes it straightforward to implement parts of these modules in Java.
• During their initialization, these modules are forced to ensure their Truffle nodes are executed immediately and never again, avoiding thread-safety issues.
• However, many stdlib modules contain hidden properties and functions implemented in Pkl, whose Truffle nodes will only be executed later and potentially multiple times.

This looks like a massive thread-safety issue, as neither Pkl's Truffle nodes nor VmObject are thread-safe.

[bioball]

The issue here (as pointed by @odenix) is specifically a race condition when executing stdlib modules (and perhaps specifically pkl:base).

Some ideas:

• Implement shared stdlib classes in Java and not in Pkl (as suggested in fix: resolve intermittent NullPointerException in LetExprNode during concurrent execution #1484 (comment))
  • We'd then remove of the much of the Pkl code in pkl:base? E.g. most of the logic in class Module?
• Have specialized Truffle nodes only for those used by the stdlib
  • we initialize functionNode lazily for perf reasons, but should be okay to initialize eagerly
  • means lots of duplication though and hard to make sure we got everything right
• In BaseModule's static block, execute Module.output.bytes

[odenix]

Sharing as few stdlib modules as possible, and implementing them entirely in Java, is a good start. Manually forcing anything not covered by VmModule.force() also seems like a good idea.