JDK-4902932 : exception target within the exception range that it's handling
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-08-07
  • Updated: 2003-08-07
  • Resolved: 2003-08-07
Related Reports
Relates :  
Description
Name: rmT116609			Date: 08/07/2003


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

FULL OS VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
I compiled the included test case code in javac, using the following compiler options:

-J-Djava.endorsed.dirs=.
-Xswitchcheck
-deprecation
-d bin
-target 1.1

looking at the javap disassembly, the exception table lists the target line at being within the exception range (try block) that it is itself handling.

This is causing a lock-up in at least one JVM implementation that I have to support. I have compared the javac output with other 3rd party compiler implementations and they do not generate a target within the exception range. Consequently, they work with all of our targeted JVM's. As far as I can tell, older versions of javac did not produce this problem either.

As a result, I cannot use javac for release builds of our product. I was hoping to migrate from the MS jvc compiler!

I have consulted with people who know the JVM spec in more detail than myself, and they suggested that this behaviour was unexpected.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
--- javap disassembly of eclipse generated class ---
public class com.m_systems.api.test.MSJVMSyncExcLockupTestApp extends java.lang.Object{
public com.m_systems.api.test.MSJVMSyncExcLockupTestApp();
  Code:
   0:   aload_0
   1:   invokespecial   #9; //Method java/lang/Object."<init>":()V
   4:   return


public static void main(java.lang.String[]);
  Code:
   0:   new     #17; //class Integer
   3:   dup
   4:   bipush  6
   6:   invokespecial   #20; //Method java/lang/Integer."<init>":(I)V
   9:   astore_1
   10:  aload_1
   11:  dup
   12:  astore_2
   13:  monitorenter
   14:  new     #22; //class NullPointerException
   17:  dup
   18:  invokespecial   #23; //Method java/lang/NullPointerException."<init>":()V
   21:  athrow
   22:  aload_2
   23:  monitorexit
   24:  athrow
  Exception table:
   from   to  target type
    14    22    22   any
}
ACTUAL -
--- javap disassembly of javac generated class ---
public class com.m_systems.api.test.MSJVMSyncExcLockupTestApp extends java.lang.Object{
public com.m_systems.api.test.MSJVMSyncExcLockupTestApp();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return


public static void main(java.lang.String[]);
  Code:
   0:   new     #2; //class Integer
   3:   dup
   4:   bipush  6
   6:   invokespecial   #3; //Method java/lang/Integer."<init>":(I)V
   9:   astore_1
   10:  aload_1
   11:  dup
   12:  astore_2
   13:  monitorenter
   14:  new     #4; //class NullPointerException
   17:  dup
   18:  invokespecial   #5; //Method java/lang/NullPointerException."<init>":()V
   21:  athrow
   22:  astore_3
   23:  aload_2
   24:  monitorexit
   25:  aload_3
   26:  athrow
  Exception table:
   from   to  target type
    14    25    22   any
}


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class JVMSyncExcLockupTestApp {
   public static void main(String[] args){
      Integer i = new Integer(6);
      synchronized (i){
         if (true){
            throw new NullPointerException();
         }
      }
   }
}

---------- END SOURCE ----------
(Incident Review ID: 194022) 
======================================================================

Comments
PUBLIC COMMENTS ...
10-06-2004

EVALUATION The self-referential exception range is necessary to generate correct code for a synchronized block. Any VM that cannot correctly run code like this is broken, and you should report it as a bug. ###@###.### 2003-08-07
07-08-2003