...




FULL PRODUCT VERSION :
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b19)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed mode)


FULL OS VERSION :
Linux skiffserv 2.5.66 #3 Fri Mar 28 12:35:32 EST 2003 i686 unknown unknown GNU/Linux

Solaris 2.8


A DESCRIPTION OF THE PROBLEM :
The 1.4.2-beta javac compiler throws a NullPointerException in com.sun.tools.javac.v8.comp.Flow.visitTry(Flow.java:873) when compiling legal java code.  The 1.4.1_02 compiler handles this code without and problems.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Download http://www.cag.lcs.mit.edu/~cananian/sunbug.tar.gz and uncompress.

% cd SUNBUG
% javac -classpath Harpoon.jar:cup.jar -source 1.4 Java12.java

EXPECTED VERSUS ACTUAL BEHAVIOR :
Successful compilation (no output).
Crashes (see error message below).

ERROR MESSAGES/STACK TRACES THAT OCCUR :
An exception has occurred in the compiler (1.4.2-beta). Please file a bug at the Java Developer Connection (http://java.sun.com/cgi-bin/bugreport.cgi)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.NullPointerException
        at com.sun.tools.javac.v8.comp.Flow.visitTry(Flow.java:873)
        at com.sun.tools.javac.v8.tree.Tree$Try.accept(Tree.java:697)
        at com.sun.tools.javac.v8.tree.TreeScanner.scan(TreeScanner.java:33)
        at com.sun.tools.javac.v8.comp.Flow.scanStat(Flow.java:483)
        at com.sun.tools.javac.v8.comp.Flow.scanStats(Flow.java:492)
        at com.sun.tools.javac.v8.comp.Flow.visitBlock(Flow.java:711)
        at com.sun.tools.javac.v8.tree.Tree$Block.accept(Tree.java:547)
        at com.sun.tools.javac.v8.tree.TreeScanner.scan(TreeScanner.java:33)
        at com.sun.tools.javac.v8.comp.Flow.scanStat(Flow.java:483)
        at com.sun.tools.javac.v8.comp.Flow.visitDoLoop(Flow.java:721)
        at com.sun.tools.javac.v8.tree.Tree$DoLoop.accept(Tree.java:565)
        at com.sun.tools.javac.v8.tree.TreeScanner.scan(TreeScanner.java:33)
        at com.sun.tools.javac.v8.comp.Flow.scanStat(Flow.java:483)
        at com.sun.tools.javac.v8.comp.Flow.scanStats(Flow.java:492)
        at com.sun.tools.javac.v8.comp.Flow.visitBlock(Flow.java:711)
        at com.sun.tools.javac.v8.tree.Tree$Block.accept(Tree.java:547)
        at com.sun.tools.javac.v8.tree.TreeScanner.scan(TreeScanner.java:33)
        at com.sun.tools.javac.v8.comp.Flow.scanStat(Flow.java:483)
        at com.sun.tools.javac.v8.comp.Flow.visitMethodDef(Flow.java:665)
        at com.sun.tools.javac.v8.tree.Tree$MethodDef.accept(Tree.java:482)
        at com.sun.tools.javac.v8.tree.TreeScanner.scan(TreeScanner.java:33)
        at com.sun.tools.javac.v8.comp.Flow.visitClassDef(Flow.java:615)
        at com.sun.tools.javac.v8.tree.Tree$ClassDef.accept(Tree.java:443)
        at com.sun.tools.javac.v8.tree.TreeScanner.scan(TreeScanner.java:33)
        at com.sun.tools.javac.v8.comp.Flow.analyzeTree(Flow.java:1161)
        at com.sun.tools.javac.v8.JavaCompiler.compile(JavaCompiler.java:361)
        at com.sun.tools.javac.v8.Main.compile(Main.java:569)
        at com.sun.tools.javac.Main.compile(Main.java:36)
        at com.sun.tools.javac.Main.main(Main.java:27)
 xxxxx@xxxxx :~/SUNBUG$

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See 'steps to reproduce'.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use the 1.4.1_02 compiler.

Release Regression From : 1.4.1_02
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 184054) 
======================================================================

N/A

I have found the cause of the problem and an appropriate fix.

Note that this problem did not appear in any FCS product.

 xxxxx@xxxxx  2003-09-05

I take it back.  Apparently this problem occurs in 1.4.1_03.

 xxxxx@xxxxx  2003-09-06

I checked other related Java sources and discovered that this 
bug will affect all projects using Lex-generated classes for 
Java.
In fact we commonly find "final" local variale declarations in 
loops, when the programmer wants to makesure that a 
variable declared in a loop will receive a value that is only 
valid for one occurence of the loop, and not reused in other 
occurences by leaving it unaffected, or unexpectedly modified 
within some untested parts of the loop. This is a convenient 
way to use a compiler type-safety feature in order to avoid 
debugging a class at run-time, notably for difficult bugs 
related to variable usage and code coverage.


This bug apparently doesnot affect for-loops or while-loops or 
switch-branches. But it seems to affect forced 
(unconditional) sub-blocks, needed to create or override some 
local variable temporarily.

Compiling with the verbose="on" flag set in the "tools" target 
of the ant's build.xml file, I see that this occurs when 
compiling the following Lex generated class:

    [javac] [checking com.ibm.icu.dev.tool.localeconverter.Lex]

Searching inthe localeconverter/Lex.java source for such do-
loops, I found a unique occurence of it in the following Lex 
method:

    public int nextToken() throws IOException {
        state = 0;
        dataBuffer.setLength(0);
        do {
            int c = input.read();
            final Transition[] transition = states[-state];
            for (int i = 0; i < transition.length; i++) {
                if (transition[i].accepts(c)) {
                    //System.out.println("state["+ -
state+"].transition["+i+"] o
n "+c+"  '"+(char)c+"' to state[");
                    state = transition[i].doAction(c, input, 
dataBuffer);
                    //println("" + -state + "]");
                    break;
                }
            }
        } while (state <= 0);
        data = null;    //dump the cached data string
        return state;
    }

The bug disappear if I comment out the "final" type specifier 
in the local declaration.
It seems that javac attempts to move the declaration out of 
the do-loop, but it also corrupts the context of the previous 
local declaration for "int c", which needs to be used in a sub-
block.
I think that this is an unsafe attempt to perform loop 
optimization by moving a "final" declaration out of the loop...

Similar NPE bug while compiling "tools" in IBM's ICU4J 2.4

E:\icu4j>java -version
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2-beta-b19)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed 
mode)

While compiling it (through invakation by latest version of 
ant):

tools:
    [javac] Compiling 36 source files to E:\icu4j\classes
    [javac] An exception has occurred in the compiler (1.4.2-
beta). Please file a bug at the Java Developer Connection 
(http://java.sun.com/cgi-bin/bugreport.cgi)  after checking 
the Bug Parade for duplicates. Include your program and the 
following diagnostic in your report.  Thank you.
    [javac] java.lang.NullPointerException
    [javac]     at com.sun.tools.javac.v8.comp.Flow.newVar
(Flow.java:332)
    [javac]     at com.sun.tools.javac.v8.comp.Flow.visitVarDef
(Flow.java:701)
    [javac]     at 
com.sun.tools.javac.v8.tree.Tree$VarDef.accept
(Tree.java:511)

    [javac]     at 
com.sun.tools.javac.v8.tree.TreeScanner.scan
(TreeScanner.java:33)
...

Sorry, the dump was truncated in the last remark for Mantis 
beta 19.

java.lang.NullPointerException
 at com.sun.tools.javac.v8.comp.Flow.newVar(Flow.java:332)
 at com.sun.tools.javac.v8.comp.Flow.visitVarDef
(Flow.java:701)
 at com.sun.tools.javac.v8.tree.Tree$VarDef.accept
(Tree.java:511)

 at com.sun.tools.javac.v8.tree.TreeScanner.scan
(TreeScanner.java:33)
 at com.sun.tools.javac.v8.comp.Flow.scanStat
(Flow.java:483)
 at com.sun.tools.javac.v8.comp.Flow.scanStats
(Flow.java:492)
 at com.sun.tools.javac.v8.comp.Flow.visitBlock
(Flow.java:711)
 at com.sun.tools.javac.v8.tree.Tree$Block.accept
(Tree.java:547)

 at com.sun.tools.javac.v8.tree.TreeScanner.scan
(TreeScanner.java:33)
 at com.sun.tools.javac.v8.comp.Flow.scanStat
(Flow.java:483)
 at com.sun.tools.javac.v8.comp.Flow.visitDoLoop
(Flow.java:721)
 at com.sun.tools.javac.v8.tree.Tree$DoLoop.accept
(Tree.java:565)

 at com.sun.tools.javac.v8.tree.TreeScanner.scan
(TreeScanner.java:33)
 at com.sun.tools.javac.v8.comp.Flow.scanStat
(Flow.java:483)
 at com.sun.tools.javac.v8.comp.Flow.scanStats
(Flow.java:492)
 at com.sun.tools.javac.v8.comp.Flow.visitBlock
(Flow.java:711)
 at com.sun.tools.javac.v8.tree.Tree$Block.accept
(Tree.java:547)

 at com.sun.tools.javac.v8.tree.TreeScanner.scan
(TreeScanner.java:33)
 at com.sun.tools.javac.v8.comp.Flow.scanStat
(Flow.java:483)
 at com.sun.tools.javac.v8.comp.Flow.visitMethodDef
(Flow.java:665)
 at com.sun.tools.javac.v8.tree.Tree$MethodDef.accept
(Tree.java:482)

 at com.sun.tools.javac.v8.tree.TreeScanner.scan
(TreeScanner.java:33)
 at com.sun.tools.javac.v8.comp.Flow.visitClassDef
(Flow.java:615)
 at com.sun.tools.javac.v8.tree.Tree$ClassDef.accept
(Tree.java:443)

 at com.sun.tools.javac.v8.tree.TreeScanner.scan
(TreeScanner.java:33)
 at com.sun.tools.javac.v8.comp.Flow.analyzeTree
(Flow.java:1161)
 at com.sun.tools.javac.v8.JavaCompiler.compile
(JavaCompiler.java:361)
 at com.sun.tools.javac.v8.Main.compile(Main.java:569)
 at com.sun.tools.javac.Main.compile(Main.java:36)

 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown 
Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke
(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.apache.tools.ant.taskdefs.compilers.Javac13.execute
(Javac13.java:98)
...

So this case seems to occur in the following pseudo-code:

class SomeClass {
    some method() {
       local variables;
       do {
          overriden local variables;
       } while(...);
    }
}

But I could not isolate the exact code that reproduce it.
It may be related to the way the new v8 compiler analyzes 
and
optimizes the code-flow for local variables, forgetting to 
allocate
stack storage space for it, when it thinks that the variable is
already allocatedand has a valid code-coverage.

This may be caused by the way some do-loops are optimized 
so that
constant expressions are moved out of the loop.