JDK-8026704 : Build failure with --enable-debug
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-10-16
  • Updated: 2013-10-30
  • Resolved: 2013-10-16
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
8 b113Fixed
Related Reports
Relates :  
JDK-8025998 - Missing LV table in lambda bodies
Description
The latest jdk8/tl forest fails to build with --enable-debug.

This failure seems to be as a result of the changes for 8025998. I have not looked into the specifics of 8025998, but I have verified that winding back the four affected files (see below) to versions pre 8025998 resolves the issue.


    langtools/src/share/classes/com/sun/tools/javac/jvm/Gen.java
    langtools/src/share/classes/com/sun/tools/javac/code/Flags.java
    langtools/src/share/classes/com/sun/tools/javac/comp/Flow.java
    langtools/src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
---
....
Compiling 4 files for BUILD_BREAKITERATOR
[Parsed DTD html32 in 155ms]
Compiling 10107 files for BUILD_JDK
An exception has occurred in the compiler (1.8.0-internal-fastdebug). 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: Value of x -1
        at com.sun.tools.javac.util.Assert.error(Assert.java:133)
        at com.sun.tools.javac.util.Assert.check(Assert.java:94)
        at com.sun.tools.javac.util.Bits.incl(Bits.java:186)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.initParam(Flow.java:1796)
        at com.sun.tools.javac.jvm.Gen$LVTAssignAnalyzer.initParam(Gen.java:2858)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitTry(Flow.java:2083)
        at com.sun.tools.javac.tree.JCTree$JCTry.accept(JCTree.java:1167)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
        at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:389)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1367)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitBlock(Flow.java:1815)
        at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:903)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
        at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:389)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1367)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitMethodDef(Flow.java:1753)
        at com.sun.tools.javac.jvm.Gen$LVTAssignAnalyzer.visitMethodDef(Gen.java:2911)
        at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:772)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
        at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:389)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1367)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitClassDef(Flow.java:1705)
        at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:687)
        at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
        at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:389)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1367)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.analyzeTree(Flow.java:2370)
        at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.analyzeTree(Flow.java:2353)
        at com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2517)
        at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:754)
        at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1554)
        at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1518)
        at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:910)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:869)
        at com.sun.tools.javac.main.Main.compile(Main.java:523)
        at com.sun.tools.javac.main.Main.compile(Main.java:381)
        at com.sun.tools.javac.main.Main.compile(Main.java:370)
        at com.sun.tools.javac.main.Main.compile(Main.java:361)
        at com.sun.tools.javac.Main.compile(Main.java:56)
        at com.sun.tools.javac.Main.main(Main.java:42)
gmake[2]: *** [/export/home/hg/repos/jdk8/tl/build/solaris-sparcv9-normal-server-fastdebug/jdk/classes/_the.batch] Error 4
gmake[1]: *** [classes-only] Error 2
make381: *** [jdk-only] Error 2
Comments
As per Jon: 8026704 is an anti-patch, meaning the "fix" was to remove an earlier patch which was bad (fix failed). 8026749 is the do-over patch. There is no need to list 8026704 in the test in that patch Marking bug as Not verified.
30-10-2013
Fix looks like a one-liner -- further updates will be in JDK-8026749
16-10-2013
Attached simple test case Test.java
16-10-2013
The problem is triggered by catch blocks in lambda expressions, such as in the following code in Files.java /** * Convert a Closeable to a Runnable by converting checked IOException * to UncheckedIOException */ private static Runnable asUncheckedRunnable(Closeable c) { return () -> { try { c.close(); } catch (IOException e) { throw new UncheckedIOException(e); } }; } Internally, catch variables are represented as parameters, and given the stack trace is in initParam, this may be an issue of a missing PARAMETER flag.
16-10-2013
Issue recreated from Paul's earlier comment
16-10-2013
Can reproduce from compile tl with the JDK tl source using: javac -verbose -g java/nio/file/Files.java -d ~/tmp/x [wrote RegularFileObject[/Users/sandoz/tmp/x/java/nio/file/Files$3.class]] An exception has occurred in the compiler (1.8.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: Value of x -1 at com.sun.tools.javac.util.Assert.error(Assert.java:133) at com.sun.tools.javac.util.Assert.check(Assert.java:94) at com.sun.tools.javac.util.Bits.incl(Bits.java:186) And the Files.class file is never written. It appears due to: private static Runnable asUncheckedRunnable(Closeable c) { return () -> { try { c.close(); } catch (IOException e) { throw new UncheckedIOException(e); } }; } Can be reproduced with this simple class: public class A { private static Runnable asUncheckedRunnable(Closeable c) { return () -> { try { c.close(); } catch (Exception e) { } }; } } Appears to be something to do with the catching of exceptions.
16-10-2013