JDK-8064516 : BCEL still corrupts generic methods if bytecode offsets are modified
  • Type: Bug
  • Component: xml
  • Sub-Component: jaxp
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-11-10
  • Updated: 2017-08-09
  • Resolved: 2014-11-11
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.
Other Other JDK 6 JDK 7 JDK 8 JDK 9
5.0u81Fixed 5.0u85Fixed 6u91Fixed 7u80Fixed 8u40Fixed 9 b40Fixed
Related Reports
Relates :  
JDK-8062608 - BCEL corrupts debug data of methods that use generics
Description
Unfortunately, the fix for jdk8062608 does not go far enough. While jdk8062608 fixed the MethodGen constructor so that the LVT is no longer corrupted, and the LVTT is correctly duplicated when "cloning" a method, the rest of the MethodGen class still has no knowledge of the VLTT. So if we subsequently modify the instruction list, only bytecode offsets in the LVT are updated, and thus the LVTT offsets become out-of-sync with the LVT, resulting in verification error.
Comments
As far as this fix doesn't impact JAXP SQE doesn't have objections to take it in CPU15_01.
12-11-2014
This fix has zero impact in the functionality provided by JAXP, nor does it impact any of the code paths even used by JAXP. Adding a testcase here would only serve to make the test suit for JAXP more brittle with virtually no increase in coverage of actual JAXP functionality or implementation. So I have decided to add the noreg-other label.
11-11-2014
Reproducer Testcase needs to be compiled with debug info (-g flag) to reproduce. Issue does not reproduce w/o fix for jdk8062608 as there needs to be a LVTT to corrupt in the first place. === $ javac -g ReproNew.java $ java ReproNew java.lang.ClassFormatError: LVTT entry for 'list' in class file ReproNewPrime does not match any LVT entry at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:759) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:317) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:266) at ReproNew.test(ReproNew.java:87) at ReproNew.main(ReproNew.java:58) ===
10-11-2014