JDK-4029944 : Compiler reports line numbers incorrectly on very big files
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.1,1.1.6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1997-02-03
  • Updated: 2000-02-03
  • Resolved: 2000-02-03
Related Reports
Duplicate :  
Duplicate :  

Name: mc57594			Date: 02/03/97

Compiler reports line numbers incorrectly on very big files.
The bag present in JDK 1.1 beta3 and JDK 1.0.2.

1) a) Generate file that has more number of lines more then 64k.
   b) make error at the end
   c) run compiler

2) I may upload file that show this problem, but is is very big
   (>1.8M). IBM was able to reproduce this problem on JDK 1.0.2
   for OS/2. It think that you will be able to reproduce this on
   any file with big number of lines. IBM suggested that line 
   numbers are rounded by 32K.

3) Not applicable
4) Not applicable
5) Not applicable

This bug casue major problems in development of one of projects
in our company.
company  -  Novosoft  , email  -  ###@###.###

WORK AROUND Name: mc57594 Date: 02/03/97 No workaround known ======================================================================

EVALUATION There is a 16-bit limit in the sizes in the LineNumberTable attribute as documented in the JVM Spec. That thing should be interpreted as an unsigned 16-bit item, so the compiler and friends should be able to deal with files up to 64k lines. If there's a wrap around at 32k lines, then that seems wrong. The compiler should probably not permit compilation of files of more than 64k lines. timothy.lindholm@Eng 1997-02-10 --- The wrap at 32k lines was caused by a distinct compiler bug, which is fixed in 1.2. The compiler should still probably make a warning at 64k lines. david.stoutamire@Eng 1997-05-16 Using the following bit of code, I was able to generate a class, BigSource, which contains an error on a line >64K. -- Big.java -- import java.io.FileWriter; import java.io.IOException; public class Big { public static void main(String [] args) { try { FileWriter out = new FileWriter("BigSource.java"); out.write("public class BigSource {\n"); out.write(" public static void main(String [] args) {\n"); out.write(" int i;\n"); for (int i = 0; i < 65536; i++) out.write(" System.out.printl(\"i: \" + i++);\n"); // the error on next line in intentional out.write(" System.out.println(i);\n"); out.write(" }\n"); out.write("}\n"); out.flush(); out.close(); } catch (IOException e) { e.printStackTrace(); System.out.println("ugh!"); } } } The compilers in jdk1.2.x and jdk1.3 use the correct line number to identify the problem line. $ jdk122; javac BigSource.java BigSource.java:4: Variable i may not have been initialized. System.out.println("i: " + i++); ^ BigSource.java:65540: Method printl(int) not found in class java.io.PrintStream. System.out.printl(i); ^ 2 errors $ jdk13; javac BigSource.java BigSource.java:65540: cannot resolve symbol symbol : method printl (int) location: class java.io.PrintStream System.out.printl(i); ^ 1 error When there is no error, the compiler in jdk1.2.x and jdk1.3 will generate a classfile which can not be run by the VM. $ jdk13; java BigSource Exception in thread "main" java.lang.ClassFormatError: BigSource (Code of a method longer than 65535 bytes) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:460) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:247) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:288) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286) at java.lang.ClassLoader.loadClass(ClassLoader.java:244) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:304) iris.garcia@eng 2000-02-01 The crash due to the compiler generating a class file which exceeds VM limits is being tracked as part of bug 4309152. iris.garcia@eng 2000-02-03