JDK-4306933 : the createStrokedShape() method crashes the HotSpot Server VM on Solaris
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2000-01-25
  • Updated: 2000-07-25
  • Resolved: 2000-07-25
Related Reports
Duplicate :  
Relates :  
Description

Name: dkC59003			Date: 01/24/2000


The regression test (testbase_nsk) nsk/regression/b4305163 crashes
the HotSpot Server VM (2.0, build A) on Solaris.

The test creates the CubicCurve2D object and then calls
the createStrokedShape() method for this object.
This call causes Unexpected Signal 11.

See test source below.

See log:

% /export/java/jdk1.2.2/solaris/bin/java -version
java version "1.2.2"
Java(TM) HotSpot Server VM (2.0, mixed mode, build A)

% /export/java/jdk1.2.2/solaris/bin/java b4305163
==> nsk/regression/b4305163 test LOG:
----> new CubicCurve2D object created!
----> CubicCurve2D object transformed into Shape object!
----> new Stroke object created!
----> createStrokedShape() - will be!
An irrecoverable stack overflow has occurred.
An irrecoverable stack overflow has occurred.
#
# HotSpot Virtual Machine Error, Unexpected Signal 11
#
# Error ID: 4F533F534F4C415249530E4350500791 01
#
(Error ID: os_solaris.cpp, 1937)


--------------------- java source ------------------------------
import java.awt.geom.*;
import java.awt.*;

public class b4305163 {
    static Stroke stroke_obj;
    static Shape shape_obj;
    static Shape stroked_shape_obj;

    public static int run(String argv[], java.io.PrintStream out) {
        System.out.println("==> nsk/regression/b4305163 test LOG:");
        CubicCurve2D ccurve = new CubicCurve2D.Float(798049, 1219070,
						     797937, 1219280,
						     798047, 1219070,
						     797997, 1219180);
        System.out.println("----> new CubicCurve2D object created!");

        shape_obj = ccurve;
        System.out.println("----> CubicCurve2D object transformed into Shape object!");

        stroke_obj = new BasicStroke();
        System.out.println("----> new Stroke object created!");

        System.out.println("----> createStrokedShape() - will be!");
        stroked_shape_obj = stroke_obj.createStrokedShape(shape_obj);
        System.out.println("----> createStrokedShape() - done!");

        System.out.println("==> nsk/regression/b4305163 test PASSED" );

        return 0/*STATUS_PASSED*/;
    }

    public static void main(String argv[]) {
        System.exit(run(argv, System.out) + 95/*STATUS_TEMP*/);
    }

}    // end of b4305163 class 

----------------------------------------------------------------
 
======================================================================

Comments
SUGGESTED FIX This description relates to the current stack overflow and stack overflow exception but can apply to other VM runtime exceptions. This is for solaris/sparc If the VM is handling (e.g., in a signal handler) a stack overflow and the thread that has experienced the overflow is currently in native code, the VM currently returns to the users code and allows the stack overflow and subsequent SEGV to occur. The VM could alternately walk the stack looking for a Java frame that can handle the stack overflow exception. A prerequisite for this latter approach is the ability to detect if the native code, through JNI, has acquired a Java monitors. In the normal unwinding of the stack to find an exception handler, all Java monitors are released. If an exception handler for the stack overflow is called it is expected that all monitors acquired downstream of that point have been released. If a Java monitor has been acquired in native code and the monitor cannot be found during the unwind (which it probably can't), then the execution of the exception handler would convey the (possibly false) proposition that all the monitors had been released. If it can be determined that the native code has not acquired any monitors, then the unwind can be done and the exception handler (if present) can be invoked. If it cannot so be determined, then a VM should proceed as it currently does. Do we currently handle this interleaving of Java and native code correctly? Java code with exception handler for A Native code which uses JNI to acquire a monitor Java code that throws exception A
11-06-2004

EVALUATION This is a bug in the test. See bug 4306935. Name: dkC59003 Date: 03/17/2000 -------------------------------------------------------- To my mind it is not correct evaluation. The referenced #4306935 bugreport does not say anything about a bug in the test, but this bugreport has been reassigned to java/classes_2D. Therefore it seems right if the current bugreport (#4306933) would be "Closed because: duplicate" (if it is actually duplicate). Next, even if this test has a any functional bug (for example, incorrect coordinates passed to CubicCurve2D.Float constructor) it should not crash the JVM but rather a relevant exception should be thrown from classes_2D. ###@###.### 2000-03-17 -------------------------------------------------------- ====================================================================== jon.masamitsu@Eng 2000-03-20 The SEGV that occurs is due to a stack overflow. hotspot does not handle very well currently. The fix to do a better job on stack overflows is not scheduled for 1.3. See bug 4306933. The test appears to be doing recursive calls to processCubic() which is native code. With hotspot there is only one frame in the stack trace. With -classic there appears to be a loop in the stack trace. In both cases the stack is probably damaged or at least dbx cannot figure it out. jon.masamitsu@Eng 2000-03-22 The VM is caughting a segv due to a stack overflow. The thread that is getting the stack overflow is in native code.
22-03-2000