Bug ID: JDK-4700707 JVM invalid memory access

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 1.3.1_03

Priority: P2
Status: Closed
Resolution: Fixed
OS: solaris_8
CPU: generic

Submitted: 2002-06-11
Updated: 2012-10-08
Resolved: 2002-08-28

Other
1.4.2 mantisFixed

Attempts to load a class generated by our application server as a result of 
compiling a JSP page results in the JVM attempting to access an invalid memory
address.

Test case: Using attached test.jar, execute java -jar test.jar

Problem has been seen on Linux, Windows 2000 and Solaris.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004
SUGGESTED FIX Patch that works for the customer's test case. Should probably throw an exception instead. % diff relocator.cpp new.relocator.cpp 2c2 < #pragma ident "@(#)relocator.cpp 1.25 01/11/27 19:43:37 JVM" --- > #pragma ident "%W% %E% %U% JVM" 379c379,385 < if (length > MAX_METHOD_LENGTH) return false; --- > if (length > MAX_METHOD_LENGTH) { > // Initialize to MAX length > if (delta == 0 && code_length() + delta < MAX_METHOD_LENGTH) > length = MAX_METHOD_LENGTH; > else > assert (length < MAX_METHOD_LENGTH, "code length > MAX_METHOD_LENGTH"); > }
11-06-2004
EVALUATION The method - method holder: '_atg_3/_jspbuild/_html/_content/_RepViewShared_xjsp' - name: '_jspService' - code size: 63327 causes the VM to encounter this bug. The code size is almost to the boundary of what the VM can handle While initializing the class the method is rewritten so that the local variables can have oop maps generated for them (the presence of jsr's complicates the control flow, hense the rewriting). During the rewrite, the VM calculates a size + slop of the new code buffer, and doesn't initialize it because the result too large, which causes the segv. If the initialization bug is fixed, the VM will report an error "could not rewrite method" if it runs out of space while trying to rewrite the method. I think it should generate an exception ExceptionInInitializerError (or maybe VirtualMachineError or even VerifyError) instead probably. This test runs fine with a simple change to initialize the size of the rewritten code stream to the maximum size. Should that part of the change be made for hopper? ###@###.### 2002-06-17 After reviewing the code the VM cannot recover from an overflow while rewriting a method and the fatal error "could not rewrite method" is the best it can do. It's in a place where it cannot raise exceptions. Also, a user will not be able to recover from such an exception. The fix is to allow initizalization of the code buffer for the rewritten code up to the max capacity 65535, which is the limit of code per non-native, non-abstract method in section 4.10 of the JVM Specification. ###@###.### 2002-08-06 Putback comment: 4700707 JVM invalid memory access while rewriting bytecodes A large method in a class generated by a user application causes the VM to core dump while rewriting bytecodes. The code size is almost to the 65K code boundary. While initializing the class the method is rewritten so that the local variables can have oop maps generated for them (the presence of jsr's complicates the control flow, hense the rewriting). During the rewrite, the VM calculates a size + slop of the new code buffer, and doesn't initialize it because the result too large, which causes the segv. I fixed the initialization to create a non-null code array using the MAX_METHOD_SIZE at least, and checked that it succeeded. I also changed the code to throw a LinkageError exception if the code array overflows while rewriting, and I also changed the code to throw VerifyError in the cases where it used to give a fatal() error from the VM when parsing the bytecodes while rewriting. eg: % gamma -jar test.jar Exception in thread "main" java.lang.LinkageError: could not rewrite method - ex ception occurred or bytecode buffer overflow in method _jspService And jck tests run with -noverify: [Enter:javasoft.sqe.tests.vm.classfmt.ins.instr_054.instr_05401m1.instr_05401m1] test instr_05401m1 failed with unexpected loading exception: java.lang.LinkageEr ror: Illegal class file encountered. Try running with -Xverify:all in method m Note that many jck tests will still core dump in classfile parsing, but these cases will throw linkageError (they were going to give a fatal error anyway so it doesn't slow down normal correct code). Webrev: http://j2se.east/~coleenp/net/philli.east/files/coleenp/mantis.bugs.ws/webrev Reviewed by: Karen Kinnear, Jane Loizeaux, Wei Tao Tested by: test program in bug vm/lang jcks -client solsparc (fastdebug) ###@###.### 2002-08-13
13-08-2002
WORK AROUND Can your application server set an upper bound on the number of bytecodes generated, say 65535*1.25 ???? ###@###.### 2002-06-17
17-06-2002