This bug occurs during building one of our applications. Initially it manifested with something like this:

# SIGSEGV (0xb) at pc=0x00007f7b5a4c9e91, pid=58139, tid=0x00007f7b0fbe7700
...
# Problematic frame:
# V [libjvm.so+0x8e0e91] Node::uncast() const+0x1

and we thought it's a C2 bug. Backtrace looks like this:

Stack: [0x00007fdeda811000,0x00007fdeda912000], sp=0x00007fdeda90ab70, free space=998k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x8e0e91] Node::uncast() const+0x1
V [libjvm.so+0x33bb8f] InlineTree::ok_to_inline(ciMethod*, JVMState*, ciCallProfile&, WarmCallInfo*, bool&)+0x35f
V [libjvm.so+0x546a05] Compile::call_generator(ciMethod*, int, bool, JVMState*, bool, float, ciKlass*, bool, bool)+0x795

The only code in InlineTree that calls Node::uncast is the recursive LF inlining code in InlineTree::try_to_inline.

The bug is hard to reproduce with C2 and so far only happened in our CI system. So, to "fix" the bug I suggested to run with Graal instead because I was 100% sure the bug would go away and we could move on. Well, not so fast...

With Graal we get NPEs. And it's reproducible 100% of the time:

org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.NullPointerException
at parsing java.lang.invoke.LambdaForm$DMH/695769007.invokeSpecial_LILIL_V(LambdaForm$DMH)
at parsing java.lang.invoke.LambdaForm$MH/143262228.guardWithCatch(LambdaForm$MH)
at parsing java.lang.invoke.LambdaForm$MH/1297027399.delegate(LambdaForm$MH)
at parsing java.lang.invoke.LambdaForm$MH/2072826771.guard(LambdaForm$MH)
at parsing java.lang.invoke.LambdaForm$MH/2026928585.linkToCallSite(LambdaForm$MH)
at parsing android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java)
at parsing android.database.sqlite.SQLiteDatabase.$$robo$$beginTransaction(SQLiteDatabase.java:507)
at org.graalvm.compiler.java.BytecodeParser.asParserError(BytecodeParser.java:1947)
at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:2635)
at org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2445)
at org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:771)
at org.graalvm.compiler.java.BytecodeParser.parseAndInlineCallee(BytecodeParser.java:1965)
at org.graalvm.compiler.java.BytecodeParser.inline(BytecodeParser.java:1890)
at org.graalvm.compiler.java.BytecodeParser.tryInline(BytecodeParser.java:1799)
at org.graalvm.compiler.java.BytecodeParser.appendInvoke(BytecodeParser.java:1434)
at org.graalvm.compiler.java.BytecodeParser.handleReplacedInvoke(BytecodeParser.java:1370)
at org.graalvm.compiler.replacements.MethodHandlePlugin.handleInvoke(MethodHandlePlugin.java:86)
<snip>
Caused by: java.lang.NullPointerException
at org.graalvm.compiler.graph.Node.markDeleted(Node.java:812)
at org.graalvm.compiler.graph.Node.safeDelete(Node.java:808)
at org.graalvm.compiler.replacements.nodes.MethodHandleNode.maybeCastArgument(MethodHandleNode.java:341)
at org.graalvm.compiler.replacements.nodes.MethodHandleNode.getTargetInvokeNode(MethodHandleNode.java:292)
at org.graalvm.compiler.replacements.nodes.MethodHandleNode.getLinkToTarget(MethodHandleNode.java:226)
at org.graalvm.compiler.replacements.nodes.MethodHandleNode.tryResolveTargetInvoke(MethodHandleNode.java:107)
at org.graalvm.compiler.replacements.MethodHandlePlugin.handleInvoke(MethodHandlePlugin.java:64)
at org.graalvm.compiler.java.BytecodeParser.tryNodePluginForInvocation(BytecodeParser.java:1767)
at org.graalvm.compiler.java.BytecodeParser.appendInvoke(BytecodeParser.java:1412)
at org.graalvm.compiler.java.BytecodeParser.genInvokeStatic(BytecodeParser.java:1268)
at org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:4089)
at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:2630)
... 105 more

To me this looks like one of the arguments in the LF is null when it shouldn't be and in fact is not a compiler bug but a core library bug (well, it still could be a compiler bug but then both, C2 and Graal, would have the same bug).

One remaining question is why does this not happen in the interpreter. I don't have an answer for that. Maybe it's something we do in the compilers that is basically not done when interpreting the byte code.

This happens on 8 and (so far) I wasn't able to run the build with 9.