JDK-8062608 : BCEL corrupts debug data of methods that use generics
  • Type: Bug
  • Component: xml
  • Sub-Component: jaxp
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-10-31
  • Updated: 2016-06-13
  • Resolved: 2014-11-07
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
7u80Fixed 8u40Fixed 9 b40Fixed
Related Reports
Relates :  
JDK-8064516 - BCEL still corrupts generic methods if bytecode offsets are modified
Relates :  
JDK-8003147 - port fix for BCEL bug 39695 to our copy bundled as part of jaxp
Description
The copy of BCEL included in jaxp appears to corrupt the LocalVariableTable (LVT) and the LocalVariableTypeTable (LVTT) of methods that use generics. This seems to be in a bug in the original BCEL source I ported over in jdk8003147. I can reproduce the same issue on the last BCEL 6.0 snapshot.

I did not notice this earlier as the porting work I did in jdk8003147 fixes generic support enough so that the corrupted classes pass HotSpot's bytecode verification. (Un)fortunately JRockit's byte code verification is much stricter and does not allow these classes to be loaded. This means that when JRockit uses BCEL to instrument classes, we end up unable to load the resulting classes. That means that this issue breaks JRockits byte code instrumentation for generic-using code.
Comments
MethodGen constructor that instantiates from an existing method will overwrite the pre-existing LocalVariableTable with the signatures from the LocalVariableTypeTable.
06-11-2014
bumped out of the new untriaged state. Next action to be defined.
04-11-2014
example of using the reproducer with JRockit: === $ javac -g Repro8062608.java $ java Repro8062608 java.lang.ClassFormatError: Repro8062608Prime : illegal LocalVariableTable descriptor: Ljava/util/ArrayList<Ljava/lang/Integer; at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:170) at Repro8062608.test(Repro8062608.java:78) at Repro8062608.main(Repro8062608.java:56) === You can also run the testcase with HotSpot and use javap to confirm corruption of the generated Repro8062608Prime.class.
31-10-2014
To reproduce: compile with -g flag and run resulting class with JRockit
31-10-2014