JDK-8020750 : Node::get_int: guarantee(t != NULL) failed: must be con
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_oracle_5.6
  • CPU: generic
  • Submitted: 2013-07-17
  • Updated: 2016-02-29
  • Resolved: 2013-10-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8Fixed hs25Fixed
Related Reports
Blocks :  
JDK-8015848 - SA: ClassWriter have to support JSR292
Relates :  
JDK-8134918 - C2: Type speculation produces mismatched unsafe accesses
Relates :  
JDK-8011888 - sa.js: TypeError: [object JSAdapter] has no such function "__has__"
Description
#  Internal Error (node.hpp:950), pid=26233, tid=1120880960
#  guarantee(t != NULL) failed: must be con
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b95) (build 1.8.0-ea-b95)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b37 mixed mode linux-amd64 compressed oops)


Current thread (0x000000001846f800):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26258, stack(0x0000000042bf4000,0x0000000042cf5000)]

Stack: [0x0000000042bf4000,0x0000000042cf5000],  sp=0x0000000042cefbe0,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9fb7ca]  VMError::report_and_die()+0x2ea
V  [libjvm.so+0x49a532]  report_vm_error(char const*, int, char const*, char const*)+0x62
V  [libjvm.so+0x273dbf]  Node::get_int() const+0x3f
V  [libjvm.so+0x5b7047]  IfNode::fold_compares(PhaseGVN*)+0x257
V  [libjvm.so+0x5b80d2]  IfNode::Ideal(PhaseGVN*, bool)+0x5a2
V  [libjvm.so+0x8b94c9]  PhaseIterGVN::transform_old(Node*)+0x79
V  [libjvm.so+0x8b598c]  PhaseIterGVN::optimize()+0x1cc
V  [libjvm.so+0x447c6f]  Compile::Optimize()+0x10f
V  [libjvm.so+0x44afd7]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1407
V  [libjvm.so+0x3a150c]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x19c
V  [libjvm.so+0x4539fa]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcba
V  [libjvm.so+0x4548f0]  CompileBroker::compiler_thread_loop()+0x570
V  [libjvm.so+0x9ad81f]  JavaThread::thread_main_inner()+0xdf
V  [libjvm.so+0x9ad94c]  JavaThread::run()+0x11c
V  [libjvm.so+0x870948]  java_start(Thread*)+0x108


Current CompileTask:
C2:  85097 11344   !   4       java.io.ObjectOutputStream::defaultWriteFields (237 bytes)
Comments
The problem is a missing top check in IfNode::fold_compares.
08-10-2013
Waiting on PSR to respond if the fix works for their test case.
08-10-2013
Jeremy, we have a pretty good idea what the bug is and how to fix it. Unfortunately we can not reproduce it and thus confirm the fix. If I'd get you a build with the fix could you verify that it fixes the issue?
03-10-2013
This is a P3, and without a working SA this is very difficult bug to debug.
01-10-2013
We may revisit this bug either after ZBB or when the SA is properly fixed.
19-09-2013
Glad to hear that!
23-07-2013
We were able to set up an environment where we can open the core file. Thanks for you help Jeremy.
23-07-2013
No. Unfortunately there is a bug somewhere I didn't know about: JDK-8011888. We have to wait until it's fixed and then we can decide if we can backport the fix or if we can reproduce the crash with a newer JDK build.
22-07-2013
Hmmm... Doing this is not working for me either. I copied the core file back to the original server. Though it was not located in the exact same file location as it was from the original core dump. Here is the output I got: $ echo $JAVA_HOME /unit/users/oracle/density_work/java/jdk1.8.0-b95 $ pwd /unit/users/oracle/density_work/java/jdk1.8.0-b95/bin $ ./java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB $JAVA_HOME/bin/java /unit/users/oracle/core.26233 Opening core file, please wait... javax.script.ScriptException: SyntaxError: sa.js#752<eval>:1:24 Expected ( but found : function readGeneration_:StatRecord(addr) { return readVMType('Generation_:StatRecord', addr);} ^ in sa.js at line number 752 javax.script.ScriptException: SyntaxError: sa.js#752<eval>:1:24 Expected ( but found : function readGeneration_:StatRecord(addr) { return readVMType('Generation_:StatRecord', addr);} ^ in sa.js at line number 752 Exception in thread "main" java.lang.RuntimeException: javax.script.ScriptException: TypeError: [object JSAdapter] has no such function "__has__" in sa.js at line number 150 at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:82) at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.start(JSJavaScriptEngine.java:434) at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.start(JSJavaScriptEngine.java:61) at sun.jvm.hotspot.CommandProcessor.postAttach(CommandProcessor.java:1739) at sun.jvm.hotspot.CommandProcessor.<init>(CommandProcessor.java:1777) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:90) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: javax.script.ScriptException: TypeError: [object JSAdapter] has no such function "__has__" in sa.js at line number 150 at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:417) at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:368) at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:169) at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78) ... 6 more Caused by: sa.js:150 TypeError: [object JSAdapter] has no such function "__has__" at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:66) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:222) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:194) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:181) at jdk.nashorn.internal.objects.NativeJSAdapter.findGetMethod(NativeJSAdapter.java:625) at jdk.nashorn.internal.runtime.ScriptObject.lookup(ScriptObject.java:1579) at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:75) at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:138) at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:229) at jdk.nashorn.internal.scripts.Script$sa.main$wrapScriptObject$_L149(sa.js:150) at jdk.nashorn.internal.scripts.Script$sa.main(sa.js:193) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:516) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:202) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:355) at jdk.nashorn.internal.runtime.ScriptRuntime.checkAndApply(ScriptRuntime.java:340) at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:366) ... 8 more Did I do something wrong?
19-07-2013
I'm still having problems opening core files with the SA. Could you try this: $ export JAVA_HOME=/unit/users/oracle/density_work/java/jdk1.8.0-b95 $ $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB $JAVA_HOME/bin/java core.26233
19-07-2013
Sure, just give me the instructions for what needs to be done. And I can do that.
19-07-2013
Alright. I've talked to Yumin about this and the SA depends heavily on the system where the core file was generated. Jeremy, can you extract some information for me from the core file or give me access to the machine?
18-07-2013
Not sure if this matters, but should the file permissions on the core file have the "execute" bits set? I noticed that the core file I tar'd up had permissions of 644. Maybe this does not matter, just taking a stab at the issue. :)
18-07-2013
Great, glad you got the core files. It was just a regular b-95 promoted build.
18-07-2013
I got the core files, thanks. Was this a promoted JDK 8 b95 or a special build?
18-07-2013
You can attach the replay file itself to this bug. Can you put the core into your home directory so I can grab it?
17-07-2013
Yes, I've got the core file and I think I've also got the replay file. Bzip2'd up, they are 105 MB so I didn't think I should attach them here. Is there a place I can put them?
17-07-2013
Do we have replay data? Is the core file still available?
17-07-2013