Graal: NPE with native-image on Akka program

Created on 4 May 2018  Â·  5Comments  Â·  Source: oracle/graal

$ native-image --version
SubstrateVM Version Info
68c7c1073a86a3d541ffb82434acc664f3096079:substratevm
a642b10d9d3c8ca79be66d5694311e769e1526a9:substratevm-enterprise
GraalVM Version 1.0.0-rc1

native-image on an Akka based program yields an NPE. Unfortunately, I'm unable to provide the source code as it is presently closed. Here's the full stacktrace in the hope that this may help understand the problem:

error: Error encountered while parsing akka.actor.dungeon.Children.swapChildrenRefs(akka.actor.dungeon.ChildrenContainer, akka.actor.dungeon.ChildrenContainer) 
Parsing context:
    parsing akka.actor.dungeon.Children.initChild(Children.scala:148)
    parsing akka.actor.dungeon.Children.initChild$(Children.scala:141)
    parsing akka.actor.ActorCell.initChild(ActorCell.scala:431)
    parsing akka.actor.LocalActorRefProvider.systemGuardian$lzycompute(ActorRefProvider.scala:629)
    parsing akka.actor.LocalActorRefProvider.systemGuardian(ActorRefProvider.scala:623)
    parsing akka.actor.ActorSystemImpl.systemGuardian(ActorSystem.scala:806)
    parsing akka.actor.ActorSystemImpl.stop(ActorSystem.scala:745)
    parsing akka.actor.ActorSystemImpl.$anonfun$terminate$1(ActorSystem.scala:847)
    parsing akka.actor.ActorSystemImpl.$anonfun$terminate$1$adapted(ActorSystem.scala:847)
    parsing akka.actor.ActorSystemImpl$$Lambda$943/444028694.apply(Unknown Source)
    parsing scala.Option.foreach(Option.scala:257)
    parsing akka.actor.ActorSystemImpl.terminate(ActorSystem.scala:847)
    parsing com.github.huntc.streambed.ApplicationProcess.main(Application.scala:277)
    parsing com.github.huntc.lora.server.GatewayServerEntryPoints$.main(GatewayServer.scala:38)
    parsing com.github.huntc.lora.server.GatewayServerEntryPoints.main(GatewayServer.scala)
    parsing com.oracle.svm.reflect.proxies.Proxy_3_GatewayServerEntryPoints_main.invoke(Unknown Source)
    parsing java.lang.reflect.Method.invoke(Method.java:498)
    parsing com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:199)
    parsing Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0)
Original error: java.lang.NullPointerException
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder$NodeIterator.node(MethodTypeFlowBuilder.java:1081)
    at org.graalvm.compiler.phases.graph.PostOrderNodeIterator.apply(PostOrderNodeIterator.java:104)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.apply(MethodTypeFlowBuilder.java:400)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.doParse(MethodTypeFlow.java:308)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.ensureParsed(MethodTypeFlow.java:298)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.addContext(MethodTypeFlow.java:105)
    at com.oracle.graal.pointsto.flow.SpecialInvokeTypeFlow.onObservedUpdate(InvokeTypeFlow.java:419)
    at com.oracle.graal.pointsto.flow.TypeFlow.notifyObservers(TypeFlow.java:345)
    at com.oracle.graal.pointsto.flow.TypeFlow.update(TypeFlow.java:387)
    at com.oracle.graal.pointsto.BigBang$2.run(BigBang.java:498)
    at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:172)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
bug native-image

Most helpful comment

@huntc I think that's the right approach. We are working on lifting some of the SubstrateVM restrictions, but there is a limit to how far we can take that if we want to preserve the fast startup/low footprint benefits. Library and framework maintainers will have to meet us half way. We will follow the discussion and support the efforts to make this happen.

All 5 comments

@huntc thank your for your report. I'll look into it.

The NPE should be fixed in https://github.com/oracle/graal/commit/ae10d57edc0107525f7a287debb1a3a932b01791. You can try building from source to get the latest bug fixes, however the Akka framework is something that we haven't tried and you might encounter some of the limitations. For reference, https://github.com/oracle/graal/issues/370 is an issue reported for Akka which turned out to be a scala compiler bug.

Thanks for the advice.

On 5 May 2018, at 08:15, Codrut Stancu notifications@github.com wrote:

The NPE should be fixed in ae10d57. You can try building from source to get the latest bug fixes, however the Akka framework is something that we haven't tried and you might encounter some of the limitations. For reference, #370 is an issue reported for Akka which turned out to be a scala compiler bug.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

As a follow up, I’ve started a discussion on Akka and Graal native-image support here: https://discuss.lightbend.com/t/akka-and-graal-s-native-image-tool/940

@huntc I think that's the right approach. We are working on lifting some of the SubstrateVM restrictions, but there is a limit to how far we can take that if we want to preserve the fast startup/low footprint benefits. Library and framework maintainers will have to meet us half way. We will follow the discussion and support the efforts to make this happen.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

janostgren picture janostgren  Â·  3Comments

gersonimo picture gersonimo  Â·  3Comments

helloguo picture helloguo  Â·  3Comments

igor-ramazanov picture igor-ramazanov  Â·  3Comments

helloguo picture helloguo  Â·  3Comments