JDK-4477785 : method with many locals crashes vm in 64-bit mode
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2001-07-09
  • Updated: 2001-10-03
  • Resolved: 2001-09-27
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
1.4.0 beta3Fixed
Related Reports
Relates :  
Relates :  
Description

Name: dkR10014			Date: 07/09/2001



The JCK-1.4 test   
vm/instr/astore_w/astore_w004/astore_w00401m1/astore_w00401m1.html
executed in 64-bit mode causes crash of HotSpot VM (JDK build 
1.4.0-beta_refresh-b70). The test fails with "Segmentation Fault".

To reproduce the issue execute the following test (class file is attached).
Test tries to store null reference into local variable 65534.

------------ astore_w00401m1.jasm ------------------------
public class  astore_w00401m1 {

public static Method run:"([Ljava/lang/String;Ljava/io/PrintStream;)I"
    stack 3 locals 3
{
        try t7, t10;
        invokestatic    Method run1:"()I";
        istore_2;
        endtry t7, t10;
        goto    L10;
        catch t7 java/lang/StackOverflowError;
        astore_2;
        goto    L10;
        catch t10 java/lang/OutOfMemoryError;
        astore_2;

  L10:  iconst_0;
        ireturn;

}

public static Method run1:"()I"
    stack 2 locals 65535
{
        aconst_null;
        astore_w  65534;
        iconst_0;
        ireturn;
}


public static Method main:"([Ljava/lang/String;)V"
    stack 2 locals 2
{
        aload_0;
        getstatic    Field java/lang/System.out:"Ljava/io/PrintStream;";
        invokestatic    Method run:"([Ljava/lang/String;Ljava/io/PrintStream;)I";
        bipush    95/*STATUS_TEMP*/;    
        iadd;
        invokestatic    Method java/lang/System.exit:"(I)V";
        return;
}

} // end Class astore_w00401m1

------------ Logs ----------------------------------------
%jasm astore_w00401m1.jasm
%
% java -d64 -version
java version "1.4.0-beta_refresh"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta_refresh-b70)
Java HotSpot(TM) 64-Bit Server VM (build 1.4.0-beta_refresh-b70, mixed mode)
%
% java -d64 -Xfuture astore_w00401m1
Segmentation Fault

----------------------------------------------------------

======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta3 FIXED IN: merlin-beta3 INTEGRATED IN: merlin-beta3 VERIFIED IN: merlin-beta3
14-06-2004

PUBLIC COMMENTS Methods containing thousands of local variables can cause an undetected stack overflow while executing in the interpreter. This fixes this exceptionally rare condition.
10-06-2004

EVALUATION The problem appears to be that the interpreter's frame-clearing code does not check to see if there is enough stack remaining. In the case given, the SP and FP are updated to reference illegal memory, well beyond the barrier page. One solution is to probe each page of extension, and if it is not readable, then signal a stack overflow. robertg@east 2001-07-11 This was fixed by computing the required stack amount and comparing it with the available stack, and throwing an exception if it causes an overflow. Note that this bug requires extremely large numbers of locals, and so should be extremely rare to the point of non-existance (other than in test suites). ###@###.### 2001-09-19
19-09-2001

SUGGESTED FIX One solution is to probe each page of stack extension, and if it is not readable, then signal a stack overflow. This should be done immediately before the stack register is set to the new value. robertg@east 2001-07-11 John Coomes pointed out some problems in implementing the above. Instead, we will compute the required stack size and compare it with the beginning of the red zone, and if the stack would go into the red zone, then throw. robertg@east 2001-08-06
06-08-2001

WORK AROUND Enlarging the interpreter stack will allow this to work: java -d64 -Xss768k astore_w00401m1 robertg@east 2001-07-11
11-07-2001