JDK-8006960 : hotspot, "impossible" assertion failure
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7u80,8u60,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-01-25
  • Updated: 2017-08-07
  • Resolved: 2015-03-02
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 7 JDK 8 JDK 9
7u85Fixed 8u60Fixed 9 b55Fixed
Related Reports
Duplicate :  
Relates :  
Description
The problem has been discovered by Maurizio Cimadamore.

Problem description:

The problem is that some tests fail with an 'impossible' assertion error; that is, an assertion of the kind:

Assert.check(ht.het(key) == o); //this method throws an AssertionError if the condition passed as argument is false

*) failure only occurs on certain test runs (i.e. 1 out of 10 runs)
*) failing test always occurs after an 'heavy' test has been ran
*)  after some digging, some information has been printed out about the objects being tested - here's the debug statements added:

o2 = com.sun.tools.javac.file.JavacFileManager@60c22955
hash(o1) = com.sun.tools.javac.file.JavacFileManager@60c22955
hash(o2) = com.sun.tools.javac.file.JavacFileManager@60c22955
(o1 == o2) = true

the two objects are indeed identical, note that this output is printed on an handler of the assertion error issued on the above statement.

Adding the debug statements was not an easy task, as soon the code was modified (i.e. by printing the objects involved in the tests) the problem disappeared. Running langtools tests with -Xint also makes the problem disappear, while it seems that the problem occur with both -client and -server options.

Given that there's no concurrency going on (that could explain differences in the value of ht.get(key) before/after the assertion), our understanding is that this is a VM bug. What do you think?

-----------------------------------------------------------------------------------------------------------------------------------------------
How to reproduce it:

The error is hard to reproduce:

There is a testing environment at: /net/t4.ie.oracle.com/export/home/langtools/repos/langtoolsMaurizio.

the following script should be executed from the given folder:

../../hgsanitycheck_multi.sh test/tools/javac/defaultMethods

The bug is very rare now that is why the script execute the tests in the given folder 20 times.

The stacktrace of the error is:

java.lang.AssertionError
	at com.sun.tools.javac.util.Assert.error(Assert.java:126)
	at com.sun.tools.javac.util.Assert.check(Assert.java:45)
	at com.sun.tools.javac.util.Context.get(Context.java:153)
	at com.sun.tools.javac.util.Context.get(Context.java:193)
	at com.sun.tools.javac.main.JavaCompiler.<init>(JavaCompiler.java:336)
	at com.sun.tools.javac.main.JavaCompiler.instance(JavaCompiler.java:91)
	at com.sun.tools.javac.main.Main.compile(Main.java:470)
	at com.sun.tools.javac.main.Main.compile(Main.java:365)
	at com.sun.tools.javac.main.Main.compile(Main.java:354)
	at com.sun.tools.javac.main.Main.compile(Main.java:345)
	at com.sun.tools.javac.Main.compile(Main.java:94)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:477)
	at com.sun.javatest.regtest.RegressionCompileCommand.run(RegressionCompileCommand.java:247)
	at com.sun.javatest.regtest.CompileAction.runCompile(CompileAction.java:556)
	at com.sun.javatest.regtest.CompileAction.runSameJVM(CompileAction.java:395)
	at com.sun.javatest.regtest.CompileAction.run(CompileAction.java:250)
	at com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:146)
	at com.sun.javatest.Script.run(Script.java:228)
	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
result: Error. compiler crashed (exit code 4)
Comments
Fix verified by regression test.
07-08-2017

SQE OK to defer it as far as the issue is not a regression introduced in 7u80
04-03-2015

I was able to pin the problem down to C2 EA that uses the BCEscapeAnalyzer to get the escape state of a newly allocated object returned by a non-inlined method [1]. EA wrongly assumes that the returned object does not escape. As a result, the 'OptimizePtrCompare' optimization removes the pointer comparison and replaces it by "not equal". [2] I was finally able to reproduce the problem with a simple regression test (see 'TestEscapeThroughInvoke.java'). While compiling the 'run' method, C2 computes the escape state of the object returned by 'create'. EA correctly determines that the object escapes while being passed to 'A::saveInto' as argument 0 (see [3]). However, EA marks 'create' as 'return allocated value' because only the escape states of caller arguments are adjusted after a call (see 'BCEscapeAnalyzer::invoke').
26-02-2015

The code is in escape.cpp in ConnectionGraph::optimize_ptr_compare() method. It could be problem there or, most likely, the connection graph misses some edges and incorrectly set escape status for some objects.
24-02-2015

-XX:-OptimizePtrCompare fixes the problem. Looks like during EA the CmpPNode is replaced by "always not equal". I'm not yet sure why.
24-02-2015

Try -XX:-OptimizePtrCompare
20-02-2015

I was able to pin the problem down to the "Iter GVN after EA" C2 optimization phase. Before, the graph is still correct and contains a PhiNode that selects 0 or 1 as input (first parameter) to CallStaticJava. Afterwards, the PhiNode is replaced by a ConINode with value 0, leading to the "xor %esi, %esi" assembly instruction.
20-02-2015

Looks like this is a bug in the C2 compiler. The generated assembly code for 'Resolve.rawInstantiate' xors the first argument (%esi) before calling Assert.check(boolean cond). This doesn't look right to me: 0x00007ffd9cfa20a4: xor %esi,%esi 0x00007ffd9cfa20a6: nop 0x00007ffd9cfa20a7: callq 0x00007ffd950466e0 ; OopMap{rbp=Oop [336]=NarrowOop [340]=NarrowOop [344]=Oop [352]=Oop [360]=Oop [40]=Oop [48]=NarrowOop [52]=NarrowOop [56]=Oop [64]=NarrowOop [68]=NarrowOop [88]=Oop [96]=Oop [104]=Oop [128]=Oop [136]=NarrowOop [144]=Oop [156]=NarrowOop [184]=Oop [208]=Oop off=9420} ;*invokestatic check ; - com.sun.tools.javac.util.Log::popDiagnosticHandler@13 (line 398) ; - com.sun.tools.javac.comp.DeferredAttr::attribSpeculative@119 (line 390) ; - com.sun.tools.javac.comp.DeferredAttr::attribSpeculative@21 (line 374) ; - com.sun.tools.javac.comp.DeferredAttr$2::complete@74 (line 291) ; - com.sun.tools.javac.comp.DeferredAttr$DeferredType::check@57 (line 257) ; - com.sun.tools.javac.comp.DeferredAttr$DeferredType::check@93 (line 244) ; - com.sun.tools.javac.comp.Resolve$MethodResultInfo::check@17 (line 1007) ; - com.sun.tools.javac.comp.Resolve$4::checkArg@17 (line 829) ; - com.sun.tools.javac.comp.Resolve$AbstractMethodCheck::argumentsAcceptable@135 (line 734) ; - com.sun.tools.javac.comp.Resolve$4::argumentsAcceptable@8 (line 838) ; - com.sun.tools.javac.comp.Resolve::rawInstantiate@478 (line 579) ; {static_call}
12-02-2015

I think it is VM / compiler related. Further investigation showed that the exception is actually _not_ thrown from a C1 compiled but from an interpreted method. I checked the Java and native stack traces when the assertion is thrown and it looks like as if 'Log.popDiagnosticHandler' is inlined into a C2 compiled version of 'Resolve.rawInstantiate'. Here are the stack traces: ### java.lang.AssertionError for thread "Thread-0" #10 prio=5 os_prio=0 tid=0x00007f4b640fc800 nid=0x498c runnable [0x00007f4b4c464000] java.lang.Thread.State: RUNNABLE ### Java stack trace: at com.sun.tools.javac.util.Assert.check(Assert.java:44) at com.sun.tools.javac.util.Log.popDiagnosticHandler(Log.java:397) at com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:390) at com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:374) at com.sun.tools.javac.comp.DeferredAttr$2.complete(DeferredAttr.java:291) at com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:257) at com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:244) at com.sun.tools.javac.comp.Resolve$MethodResultInfo.check(Resolve.java:1007) at com.sun.tools.javac.comp.Resolve$4.checkArg(Resolve.java:829) at com.sun.tools.javac.comp.Resolve$AbstractMethodCheck.argumentsAcceptable(Resolve.java:734) at com.sun.tools.javac.comp.Resolve$4.argumentsAcceptable(Resolve.java:838) at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:579) at com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1442) at com.sun.tools.javac.comp.Resolve.findMethodInScope(Resolve.java:1629) at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1701) at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1673) at com.sun.tools.javac.comp.Resolve.findFun(Resolve.java:1834) at com.sun.tools.javac.comp.Resolve$8.doLookup(Resolve.java:2344) at com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3044) at com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3293) at com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3278) at com.sun.tools.javac.comp.Resolve.resolveMethod(Resolve.java:2340) at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:3068) at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2190) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:538) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1789) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1600) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:538) at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:584) at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1556) at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1418) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:538) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:607) at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:626) at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1082) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:986) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:538) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:607) at com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:973) at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:838) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:538) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:607) at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:4262) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4170) at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4099) at com.sun.tools.javac.comp.Attr.attrib(Attr.java:4074) at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1223) at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1196) at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:361) at com.sun.tools.javac.api.JavacTaskImpl$3.call(JavacTaskImpl.java:338) at com.sun.tools.javac.api.JavacTaskImpl$3.call(JavacTaskImpl.java:335) at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:127) at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:335) at TypeInferenceComboTest.run(TypeInferenceComboTest.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) ### Native stack trace: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j com.sun.tools.javac.util.Assert.check(Z)V+4 J 5381 C2 com.sun.tools.javac.comp.Resolve.rawInstantiate(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/code/Symbol;Lcom/sun/tools/javac/comp/Attr$ResultInfo;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/util/List;ZZLcom/sun/tools/javac/util/Warner;)Lcom/sun/tools/javac/code/Type; (491 bytes) @ 0x00007f4b5d0d0e1c [0x00007f4b5d0ce1c0+0x2c5c] J 5280 C2 com.sun.tools.javac.comp.Resolve.selectBest(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/code/Symbol;Lcom/sun/tools/javac/code/Symbol;ZZZ)Lcom/sun/tools/javac/code/Symbol; (350 bytes) @ 0x00007f4b5d07014c [0x00007f4b5d070000+0x14c] J 5217 C2 com.sun.tools.javac.comp.Resolve.findMethodInScope(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/util/Name;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/code/Scope;Lcom/sun/tools/javac/code/Symbol;ZZZZ)Lcom/sun/tools/javac/code/Symbol; (73 bytes) @ 0x00007f4b5d007328 [0x00007f4b5d007000+0x328] J 5242 C2 com.sun.tools.javac.comp.Resolve.findMethod(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/util/Name;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/code/Symbol;ZZZ)Lcom/sun/tools/javac/code/Symbol; (435 bytes) @ 0x00007f4b5d028be0 [0x00007f4b5d028760+0x480] J 3456 C1 com.sun.tools.javac.comp.Resolve.findMethod(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/util/Name;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/util/List;ZZZ)Lcom/sun/tools/javac/code/Symbol; (37 bytes) @ 0x00007f4b55ed45bc [0x00007f4b55ed4500+0xbc] J 4792 C1 com.sun.tools.javac.comp.Resolve.findFun(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/util/Name;Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/util/List;ZZ)Lcom/sun/tools/javac/code/Symbol; (524 bytes) @ 0x00007f4b5646f2f4 [0x00007f4b5646f100+0x1f4] J 4791 C1 com.sun.tools.javac.comp.Resolve$8.doLookup(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/comp/Resolve$MethodResolutionPhase;)Lcom/sun/tools/javac/code/Symbol; (29 bytes) @ 0x00007f4b5646e3dc [0x00007f4b5646e200+0x1dc] J 3468 C1 com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/comp/Resolve$MethodResolutionPhase;)Lcom/sun/tools/javac/code/Symbol; (38 bytes) @ 0x00007f4b55ed504c [0x00007f4b55ed4f40+0x10c] J 3314 C1 com.sun.tools.javac.comp.Resolve.lookupMethod(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/util/JCDiagnostic$DiagnosticPosition;Lcom/sun/tools/javac/code/Symbol;Lcom/sun/tools/javac/comp/Resolve$MethodResolutionContext;Lcom/sun/tools/javac/comp/Resolve$LookupHelper;)Lcom/sun/tools/javac/code/Symbol; (174 bytes) @ 0x00007f4b55e1c7d4 [0x00007f4b55e1c040+0x794] J 5018 C2 com.sun.tools.javac.comp.Attr.visitIdent(Lcom/sun/tools/javac/tree/JCTree$JCIdent;)V (569 bytes) @ 0x00007f4b5cf2a54c [0x00007f4b5cf2a2c0+0x28c] J 3530 C2 com.sun.tools.javac.tree.JCTree$JCIdent.accept(Lcom/sun/tools/javac/tree/JCTree$Visitor;)V (6 bytes) @ 0x00007f4b5cce2924 [0x00007f4b5cce28e0+0x44] J 4020 C2 com.sun.tools.javac.comp.Attr.attribTree(Lcom/sun/tools/javac/tree/JCTree;Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/comp/Attr$ResultInfo;)Lcom/sun/tools/javac/code/Type; (148 bytes) @ 0x00007f4b5cd65c98 [0x00007f4b5cd65c00+0x98] J 3484 C1 com.sun.tools.javac.comp.Attr.visitApply(Lcom/sun/tools/javac/tree/JCTree$JCMethodInvocation;)V (810 bytes) @ 0x00007f4b55f17984 [0x00007f4b55f13280+0x4704] J 4250 C2 com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(Lcom/sun/tools/javac/tree/JCTree$Visitor;)V (6 bytes) @ 0x00007f4b5cd8df24 [0x00007f4b5cd8dee0+0x44] J 4020 C2 com.sun.tools.javac.comp.Attr.attribTree(Lcom/sun/tools/javac/tree/JCTree;Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/comp/Attr$ResultInfo;)Lcom/sun/tools/javac/code/Type; (148 bytes) @ 0x00007f4b5cd65c98 [0x00007f4b5cd65c00+0x98] J 4507 C1 com.sun.tools.javac.comp.Attr.visitExec(Lcom/sun/tools/javac/tree/JCTree$JCExpressionStatement;)V (25 bytes) @ 0x00007f4b5638f47c [0x00007f4b5638f0c0+0x3bc] J 4939 C2 com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(Lcom/sun/tools/javac/tree/JCTree$Visitor;)V (6 bytes) @ 0x00007f4b5ceecfa4 [0x00007f4b5ceecf60+0x44] J 4640 C2 com.sun.tools.javac.comp.Attr.attribStat(Lcom/sun/tools/javac/tree/JCTree;Lcom/sun/tools/javac/comp/Env;)Lcom/sun/tools/javac/code/Type; (80 bytes) @ 0x00007f4b5ce59180 [0x00007f4b5ce58d80+0x400] J 4506 C1 com.sun.tools.javac.comp.Attr.visitBlock(Lcom/sun/tools/javac/tree/JCTree$JCBlock;)V (357 bytes) @ 0x00007f4b5638c55c [0x00007f4b5638a0c0+0x249c] J 4736 C2 com.sun.tools.javac.tree.JCTree$JCBlock.accept(Lcom/sun/tools/javac/tree/JCTree$Visitor;)V (6 bytes) @ 0x00007f4b5cea1c24 [0x00007f4b5cea1be0+0x44] J 4640 C2 com.sun.tools.javac.comp.Attr.attribStat(Lcom/sun/tools/javac/tree/JCTree;Lcom/sun/tools/javac/comp/Env;)Lcom/sun/tools/javac/code/Type; (80 bytes) @ 0x00007f4b5ce59180 [0x00007f4b5ce58d80+0x400] J 5245 C2 com.sun.tools.javac.comp.Attr.visitMethodDef(Lcom/sun/tools/javac/tree/JCTree$JCMethodDecl;)V (1198 bytes) @ 0x00007f4b5d04befc [0x00007f4b5d04a820+0x16dc] J 3953 C2 com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(Lcom/sun/tools/javac/tree/JCTree$Visitor;)V (6 bytes) @ 0x00007f4b5cd4b2a4 [0x00007f4b5cd4b260+0x44] J 4640 C2 com.sun.tools.javac.comp.Attr.attribStat(Lcom/sun/tools/javac/tree/JCTree;Lcom/sun/tools/javac/comp/Env;)Lcom/sun/tools/javac/code/Type; (80 bytes) @ 0x00007f4b5ce59180 [0x00007f4b5ce58d80+0x400] J 4147 C1 com.sun.tools.javac.comp.Attr.attribClassBody(Lcom/sun/tools/javac/comp/Env;Lcom/sun/tools/javac/code/Symbol$ClassSymbol;)V (730 bytes) @ 0x00007f4b5623690c [0x00007f4b56232780+0x418c] J 5145 C2 com.sun.tools.javac.comp.Attr.attribClass(Lcom/sun/tools/javac/code/Symbol$ClassSymbol;)V (515 bytes) @ 0x00007f4b5cf9ac4c [0x00007f4b5cf9a380+0x8cc] J 2772 C1 com.sun.tools.javac.comp.Attr.attrib(Lcom/sun/tools/javac/comp/Env;)V (40 bytes) @ 0x00007f4b55bc02dc [0x00007f4b55bbfe20+0x4bc] J 5266 C1 com.sun.tools.javac.main.JavaCompiler.attribute(Lcom/sun/tools/javac/comp/Env;)Lcom/sun/tools/javac/comp/Env; (245 bytes) @ 0x00007f4b565df074 [0x00007f4b565dd020+0x2054] J 3632 C1 com.sun.tools.javac.main.JavaCompiler.attribute(Ljava/util/Queue;)Ljava/util/Queue; (47 bytes) @ 0x00007f4b55fcd2a4 [0x00007f4b55fccde0+0x4c4] J 4201 C1 com.sun.tools.javac.api.JavacTaskImpl.analyze(Ljava/lang/Iterable;)Ljava/lang/Iterable; (99 bytes) @ 0x00007f4b5627cf9c [0x00007f4b5627cc00+0x39c] J 4000 C1 com.sun.tools.javac.api.JavacTaskImpl$3.call()Ljava/lang/Object; (5 bytes) @ 0x00007f4b56193e54 [0x00007f4b56193d80+0xd4] J 4485 C1 com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(Ljava/util/concurrent/Callable;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (179 bytes) @ 0x00007f4b5636c7e4 [0x00007f4b5636c6c0+0x124] J 4482 C1 com.sun.tools.javac.api.JavacTaskImpl.analyze()Ljava/lang/Iterable; (22 bytes) @ 0x00007f4b56363124 [0x00007f4b56362f20+0x204] J 3619 C1 TypeInferenceComboTest.run()V (140 bytes) @ 0x00007f4b55fd243c [0x00007f4b55fd1920+0xb1c] j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+95 j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V [libjvm.so+0x634b9a] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0xeea V [libjvm.so+0x6322a4] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x2a4 V [libjvm.so+0x63288a] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x4a V [libjvm.so+0x6a0cee] thread_entry(JavaThread*, Thread*)+0x8e V [libjvm.so+0x9d1ab8] JavaThread::thread_main_inner()+0xd8 V [libjvm.so+0x9d1c58] JavaThread::run()+0x158 V [libjvm.so+0x8869e2] java_start(Thread*)+0xf2 C [libpthread.so.0+0x77f1] An exception has occurred in the compiler (1.9.0-internal). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.AssertionError at com.sun.tools.javac.util.Assert.error(Assert.java:125) at com.sun.tools.javac.util.Assert.check(Assert.java:44) at com.sun.tools.javac.util.Log.popDiagnosticHandler(Log.java:397) [...]
12-02-2015

Do you think it's not the VM then?
11-02-2015

I modified the C1 compiler to add 'hlt' instructions to the unequal-branch of 'Log.popDiagnosticHandler' and also to the static call stub, exception handler, deopt handler and unwind handler and it looks like as if these are never executed.
11-02-2015

That's odd. Maybe a deoptimization problem?
11-02-2015

Able to reproduce. Compared the generated assembly code of a successful run against a failing run: no differences (see attached 'disassemby-success-level-3.txt'). Trying to verify correctness of generated code.
10-02-2015

http://scaaa008.us.oracle.com:9502/runs%2F715078.JDK9-LANGTOOLS-NIGHTLY-4/results/workDir/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.jtr #section:main ----------messages:(3/152)---------- command: main TypeInferenceComboTest reason: User specified action: run main/othervm/timeout=360 TypeInferenceComboTest elapsed time (seconds): 96.505 ----------System.out:(0/0)---------- ----------System.err:(1281/88734)---------- An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.AssertionError at com.sun.tools.javac.util.Assert.error(Assert.java:125) at com.sun.tools.javac.util.Assert.check(Assert.java:44) at com.sun.tools.javac.util.Log.popDiagnosticHandler(Log.java:397) at com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:390) at com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:374) at com.sun.tools.javac.comp.DeferredAttr$2.complete(DeferredAttr.java:291) at com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:257) at com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:244) at com.sun.tools.javac.comp.Resolve$MethodResultInfo.check(Resolve.java:1007) at com.sun.tools.javac.comp.Resolve$4.checkArg(Resolve.java:829) at com.sun.tools.javac.comp.Resolve$AbstractMethodCheck.argumentsAcceptable(Resolve.java:734) at com.sun.tools.javac.comp.Resolve$4.argumentsAcceptable(Resolve.java:838) at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:579) at com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1442) at com.sun.tools.javac.comp.Resolve.findMethodInScope(Resolve.java:1629) at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1701) at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1673) at com.sun.tools.javac.comp.Resolve.findFun(Resolve.java:1834) at com.sun.tools.javac.comp.Resolve$8.doLookup(Resolve.java:2344) at com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3044) at com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3293) at com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3278) at com.sun.tools.javac.comp.Resolve.resolveMethod(Resolve.java:2340) at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:3068) at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2190) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:538) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1789) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1600) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:538) RULE tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java Exception java.lang.AssertionError RULE tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java Exception java.lang.AssertionError: ... errors found
05-02-2015

[~thartmann], could you have a look at the generated code and find what's wrong?
05-02-2015

Got another one with a level 2 compile: + /java/re/jdk/9/promoted/latest/binaries/linux-amd64/bin/java -XX:CompileCommand=print,com.sun.tools.javac.util.Log::popDiagnosticHandler -Xmx1024M -Xbootclasspath/p:/scratch/twisti/8023056/build/jdk.compiler/classes -ea:com.sun.tools... -classpath classes TypeInferenceComboTest CompileCommand: print com/sun/tools/javac/util/Log.popDiagnosticHandler Java HotSpot(TM) 64-Bit Server VM warning: printing of assembly code is enabled; turning on DebugNonSafepoints to gain additional output Compiled method (c1) 1816 3385 2 com.sun.tools.javac.util.Log::popDiagnosticHandler (25 bytes) total in heap [0x00007efee9d51490,0x00007efee9d51a08] = 1400 relocation [0x00007efee9d515b8,0x00007efee9d515f8] = 64 main code [0x00007efee9d51600,0x00007efee9d517a0] = 416 stub code [0x00007efee9d517a0,0x00007efee9d51848] = 168 oops [0x00007efee9d51848,0x00007efee9d51850] = 8 metadata [0x00007efee9d51850,0x00007efee9d51868] = 24 scopes data [0x00007efee9d51868,0x00007efee9d518e8] = 128 scopes pcs [0x00007efee9d518e8,0x00007efee9d519e8] = 256 dependencies [0x00007efee9d519e8,0x00007efee9d519f0] = 8 nul chk table [0x00007efee9d519f0,0x00007efee9d51a08] = 24 Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled OopMapSet contains 6 OopMaps #0 OopMap{[64]=Oop [72]=Oop [80]=Oop off=276} #1 OopMap{rsi=Oop rdx=Oop off=304} #2 OopMap{rsi=Oop off=314} #3 OopMap{[72]=Oop [80]=Oop off=334} #4 OopMap{[80]=Oop [72]=Oop off=344} #5 OopMap{[80]=Oop [72]=Oop off=352} An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.AssertionError java.lang.AssertionError java.lang.AssertionError java.lang.AssertionError
05-02-2015

Could not reproduce it with -XX:TieredStopAtLevel=3.
04-02-2015

Finally I got it to reproduce with CompileCommand=print: + /java/re/jdk/9/promoted/latest/binaries/linux-amd64/bin/java -XX:CompileCommand=print,com.sun.tools.javac.util.Log::popDiagnosticHandler -Xmx1024M -Xbootclasspath/p:/scratch/twisti/8023056/build/jdk.compiler/classes -ea:com.sun.tools... -classpath classes TypeInferenceComboTest CompileCommand: print com/sun/tools/javac/util/Log.popDiagnosticHandler Java HotSpot(TM) 64-Bit Server VM warning: printing of assembly code is enabled; turning on DebugNonSafepoints to gain additional output Compiled method (c1) 1659 3336 3 com.sun.tools.javac.util.Log::popDiagnosticHandler (25 bytes) total in heap [0x00007f5d8615a190,0x00007f5d8615a8d8] = 1864 relocation [0x00007f5d8615a2b8,0x00007f5d8615a310] = 88 main code [0x00007f5d8615a320,0x00007f5d8615a600] = 736 stub code [0x00007f5d8615a600,0x00007f5d8615a6a8] = 168 oops [0x00007f5d8615a6a8,0x00007f5d8615a6b0] = 8 metadata [0x00007f5d8615a6b0,0x00007f5d8615a6c8] = 24 scopes data [0x00007f5d8615a6c8,0x00007f5d8615a768] = 160 scopes pcs [0x00007f5d8615a768,0x00007f5d8615a8b8] = 336 dependencies [0x00007f5d8615a8b8,0x00007f5d8615a8c0] = 8 nul chk table [0x00007f5d8615a8c0,0x00007f5d8615a8d8] = 24 Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled OopMapSet contains 8 OopMaps #0 OopMap{[64]=Oop [72]=Oop [80]=Oop off=548} #1 OopMap{rsi=Oop rdx=Oop off=576} #2 OopMap{rsi=Oop rdx=Oop off=599} #3 OopMap{rsi=Oop off=609} #4 OopMap{[80]=Oop [72]=Oop off=627} #5 OopMap{[72]=Oop [80]=Oop off=652} #6 OopMap{[80]=Oop [72]=Oop off=662} #7 OopMap{[80]=Oop [72]=Oop off=670} An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. An exception has occurred in the compiler (1.9.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.AssertionError java.lang.AssertionError java.lang.AssertionError java.lang.AssertionError at com.sun.tools.javac.util.Assert.error(Assert.java:125) at com.sun.tools.javac.util.Assert.error(Assert.java:125) at com.sun.tools.javac.util.Assert.error(Assert.java:125) at com.sun.tools.javac.util.Assert.error(Assert.java:125) at com.sun.tools.javac.util.Assert.check(Assert.java:44) at com.sun.tools.javac.util.Assert.check(Assert.java:44) at com.sun.tools.javac.util.Assert.check(Assert.java:44) at com.sun.tools.javac.util.Log.popDiagnosticHandler(Log.java:397) at com.sun.tools.javac.util.Log.popDiagnosticHandler(Log.java:397)
04-02-2015

Couldn't get it to reproduce with -XX:-TieredCompilation or -XX:TieredStopAtLevel=1 or even -XX:CompileCommand=print,com.sun.tools.javac.util.Log::popDiagnosticHandler. Not sure why the last one would change anything.
04-02-2015

Thanks. I can reproduce the problem on a random Linux box using a jdk9 repository and the latest promoted JDK 9 build.
04-02-2015

Could you attach the test case that reproduces the problem? Also, on what platform does it reproduce?
03-02-2015

Raising priority as this is affecting clean test runs during integration jobs.
03-02-2015

This started to hit again (see JDK-8067976 - spurious failures with TypeInferenceComboTest). To reproduce that issue, I created a small shell driver which would simply run the regression test 100 times. I then tried it, and it immediately found an issue on run #7. I then tried to narrow down the issue - the problematic assertion is thrown in the code below (in com/sun/tools/javac/util/Log.java): public void popDiagnosticHandler(DiagnosticHandler h) { Assert.check(diagnosticHandler == h); diagnosticHandler = h.prev; } So, the assertion error seems to indicate that diagnosticHandler != h for some reason. I then tried to add some naive println statements, to show the value of the variables - but then the issue was not reproducible anymore - which made me think of this very bug - which also had similar fuzzy behavior. Recalling the discussion I had back then, I recollected that the only way I could debug some information for the failing assertion, was to add a try/catch block - I then rewrote the above method as follows: public void popDiagnosticHandler(DiagnosticHandler h) { DiagnosticHandler dh = diagnosticHandler; try { Assert.check(dh == h); } catch (AssertionError ex) { throw new AssertionError("check = " + (dh == h)); } diagnosticHandler = h.prev; } As you see, the same test (dh == h) is repeated two times, once before the Assert.check method is called, once after it failed. To avoid multithreading issue, I stored values in local variables, which should make this code robust to i.e. multiple threads calling the same method at the same time (although this is not the case, given that I verified that each thread has its own Log instance). After spinning again the test driver, here's what I got: java.lang.AssertionError: check = true at com.sun.tools.javac.util.Log.popDiagnosticHandler(Log.java:401) at com.sun.tools.javac.util.Log.popDiagnosticHandler(Log.java:401) at com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:390) at com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:374) at com.sun.tools.javac.comp.DeferredAttr$2.complete(DeferredAttr.java:291) at com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:257) This doesn't make sense! The assertion has been issued because we passed a false condition to Assert.check and yet that very same condition prints out as 'true' in the body of the 'catch' clause! This is definitively weird, and I now suspect there really is a string connection between the issue we are seeing in JDK-8067976 and this one.In fact, it's possible to simply tweak the original code so that the assertion never fails: public void popDiagnosticHandler(DiagnosticHandler h) { Assert.check(diagnosticHandler == h, h.toString()); diagnosticHandler = h.prev; } For some reason, calling a method on 'h' disables whatever optimization HS is doing there. I can get 100 successful test runs with this code. Another way to get clean sheets is to pass the "-vmoption:-XX:-TieredCompilation" option to jtreg, which effectively disables tiered compilation. Again, with this option and no change in the code I get 100 successful runs. Note: I tried to tweak the test TypeInferenceComboTest so that it runs endlessly until a failure is found (in order to avoid having to use a driver shell script) but, perhaps not surprisingly, the failure cannot be reproduced in that mode - which seems consistent with the bug being caused by the transition from C1 to C2 code.
03-02-2015

ILW=assertions fail in "impossible" ways, very rare, none=MLH=P4
16-05-2014

I changed the jdk back to what was there openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-viromero_2013_04_18_11_55-b00) OpenJDK 64-Bit Server VM (build 25.0-b28, mixed mode) but still get /export/home/langtools/repos/langtools-sby/src/share/classes/com/sun/tools/javac/comp/Resolve.java:761: error: no suitable method found for report(MethodCheckDiag,InferenceContext,JCDiagnostic) [javac] report(methodDiag, deferredAttrContext.inferenceContext, details); [javac] ^ [11:40:30 AM] Bharadwaj Yadavalli: openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-viromero_2013_04_18_11_55-b00) OpenJDK 64-Bit Server VM (build 25.0-b28, mixed mode)
27-09-2013

In order to be able to compile the code you will need to add this line: @SuppressWarnings("overrides") just before the definition of Resolve.MethodResolutionContext.Candidate to get: @SuppressWarnings("overrides") class Candidate {...} The code has changed since the bug was reported and I think it could be useful to check if the bug is still reproducible with the given compiler code rather than updating it to tip in which case you would add too much variation. Thanks.
27-09-2013

Do you still see this failure? I tried to reproduce this failure on t4.ie.oracle.com by creating a parallel directory to langtoolsMaurizio with its contents. I also made the necessary changes to the script hgsanitycheck_multi.sh. I copied jdk-1.8.0 (b108) $ /export/home/langtools/jdk1.8.0/bin/java -d64 -server -Xinternalversion Java HotSpot(TM) 64-Bit Server VM (25.0-b50) for solaris-sparc JRE (1.8.0-ea-b108), built on Sep 19 2013 00:42:35 by "" with Sun Studio 12u1 I get the following result: build-bootstrap-javac: [mkdir] Created dir: /export/home/langtools/repos/langtools-sby/build/bootstrap/gensrc [mkdir] Created dir: /export/home/langtools/repos/langtools-sby/build/bootstrap/classes [pcompile] Generating 8 resource files to /export/home/langtools/repos/langtools-sby/build/bootstrap/gensrc [copy] Copying 1 file to /export/home/langtools/repos/langtools-sby/build/bootstrap/gensrc [pcompile] Generating 1 resource files to /export/home/langtools/repos/langtools-sby/build/bootstrap/gensrc [javac] Compiling 368 source files to /export/home/langtools/repos/langtools-sby/build/bootstrap/classes [javac] /export/home/langtools/repos/langtools-sby/src/share/classes/com/sun/tools/javac/comp/Resolve.java:761: error: no suitable method found for report(MethodCheckDiag,InferenceContext,JCDiagnostic) [javac] report(methodDiag, deferredAttrContext.inferenceContext, details); [javac] ^ [javac] method Resolve.MethodCheckContext.report(DiagnosticPosition,JCDiagnostic) is not applicable [javac] (actual and formal argument lists differ in length) [javac] method <anonymous com.sun.tools.javac.comp.Resolve$2$2>.report(DiagnosticPosition,JCDiagnostic) is not applicable [javac] (actual and formal argument lists differ in length) [javac] /export/home/langtools/repos/langtools-sby/src/share/classes/com/sun/tools/javac/comp/Resolve.java:3515: warning: [overrides] Class Resolve.MethodResolutionContext.Candidate overrides equals, but neither it nor any superclass overrides hashCode method [javac] class Candidate { [javac] ^ [javac] 1 error [javac] 1 warning BUILD FAILED /export/home/langtools/repos/langtools-sby/make/build.xml:493: The following error occurred while executing this line: /export/home/langtools/repos/langtools-sby/make/build.xml:838: Compile failed; see the compiler error output for details. Total time: 11 seconds Running regression test... please wait Directory "/export/home/langtools/repos/langtools-sby/build-sby/JTwork1" not found: creating Directory "/export/home/langtools/repos/langtools-sby/build-sby/JTreport1" not found: creating Test results: passed: 35; failed: 1 Please let me know of a way to reproduce the reported issue. Thanks.
25-09-2013

If -Xint doesn't have the problem then this would seem to be a compiler (C1/C2) bug not runtime.
30-01-2013

Also, note that this problem might have been there for a long time - but it only started to appear when this langtools change was pushed: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67b01d295cd2 The changeset does not altern the compiler behavior in a significant way, but it swaps the order in which the initializers of two compiler classes (JavaFileManager and JavaCompiler) are created - this shouldn't be a problem given the fact that javac supports a lazy instantiation scheme - all classes are registered into a context when they are created, and later attempts to re-initialize the class will just end up in retrieving the previously created object. If the order of initialization is reverted, the problem cannot be reproduced. If all compiler regression tests are executed (and not just one test folder) the problem cannot be reproduced as well. Furthermore, most attempts to change the code near the place where the 'impossible assertion' occurs (i.e by printing out value of objects) will make the bug disappear. To get the above information about object identities I had to hack my way through in a rather cumbersome way, by executing the test in a different method that was called inside a try/catch block and then catching exceptions thrown by it and print the object values. If I tried to print object values inline, the bug would not reproduce.
29-01-2013

I think it's unlikely that there is any relationship with default method support - we are getting this problem even when running tests on different test folders that do not contain default method tests. We have chosen to include that one because it was the faster to run - which allowed to reproduced the bug more quickly.
29-01-2013

I would start by looking at the defaultMethod test and the vm defaultMethod implementation. However this could be in the lambda runtime. I am surprised this wasn't seen in the lambda repository?
29-01-2013

Please let us know should you need further assistance in reproducing the problem.
25-01-2013