United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6294277 java -Xdebug crashes on SourceDebugExtension attribute larger than 64K
JDK-6294277 : java -Xdebug crashes on SourceDebugExtension attribute larger than 64K

Details
Type:
Bug
Submit Date:
2005-07-06
Status:
Closed
Updated Date:
2013-07-18
Project Name:
JDK
Resolved Date:
2012-07-17
Component:
hotspot
OS:
linux,generic
Sub-Component:
jvmti
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_35,5.0,6u32,7
Fixed Versions:
hs24 (b16)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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


ADDITIONAL OS VERSION INFORMATION :
Debian GNU/Linux 2.6.6-2-686
Windows 2000

A DESCRIPTION OF THE PROBLEM :
This bug occurs when a class file contains a SourceDebugExtension attribute larger than 65535 bytes. In that case, running the java virtual machine with the debugger enable (with -Xdebug) causes a java.lang.InternalError to be thrown, as specified below.

According to the Java Virtual Machine Specification, attributes have a length coded on 4 bytes. Furthermore, JSR 045, which specifies the SourceDebugExtension attribute, does not specify such limitation on the length of the attribute. It even states that "The SMAP allows a virtually unlimited number of source files per stratum." It therefore looks like the current implementation violates the specifications.

Compilers for non-Java languages, which are the explicit audience of the SourceDebugExtension attribute, are at liberty to compile multiple source files into the same class file. In that case, it is very easy to need more than 64K map to represent source line information in that class file. We have indeed run into that situation ourselves. Therefore, we would greatly appreciate if this bug was fixed in a timely fashion.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Create a class file with a SourceDebugExtension attribute larger than 65535 bytes and some main method.
2) Run that class with 'java -Xdebug'.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The method should be executed normally.
ACTUAL -
  Program execution was aborted by the java.lang.InternalError exception described below.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.InternalError: name is too long to represent
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
This cannot be triggered by java source code, as the crucial element is the large SourceDebugExtension attribute.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The SourceDebugExtension attribute can be stripped out prior to execution, losing the benefits of JSR 045. Similarly, the 1.3 versions of the JVM do no fail in this situation, most likely because they ignore that attribute, therefore also losing the benefits of JSR 045.
###@###.### 2005-07-06 03:52:29 GMT

                                    

Comments
EVALUATION

The support of the SourceDebugExtension attribute in the HotSpot also contains a bug in the jvmtiClassFileReconstituter:

  write_attribute_name_index("SourceDebugExtension");
  write_u4(2);  // always length 2
  write_u2(symbol_to_cpool_index(ikh()->source_debug_extension()));

The classfile reconstituter assumes that the value of the debug_extension is stored
in the constant pool. This is wrong, the spec says that the value is stored in
the attribute itself:

  SourceDebugExtension_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u1 debug_extension[attribute_length];
  }
                                     
2012-06-11
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/04ade88d9712
                                     
2012-07-09
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/04ade88d9712
                                     
2012-07-14
EVALUATION

http://hg.openjdk.java.net/hsx/hsx23.6/hotspot/rev/0b8461989634
                                     
2012-09-14



Hardware and Software, Engineered to Work Together