JDK-4306103 : HS 1.3-rc1S crashes with exit code 128 against the stress-test jck122007
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-01-21
  • Updated: 2000-02-24
  • Resolved: 2000-02-24
Related Reports
Relates :  
JDK-4375107 - HS1.3.1(solx86) crashes on the stress test jck122007
Description
HS 1.3-rc1S (win32) exits with status code 128 while trying to execute 
the stress test jck122007. The test could be found in the sub-directory:
    ${TESTBASE}/src/nsk/stress/jck122/jck122007
in the testbase_nsk testbase:
    TESTBASE=/net/sqesvr/vsn/testbase/testbase_nsk

To reproduce the failure try the script DOIT.BAT in the directory:
    /net/sqesvr/vsn/GammaBase/Bugs/<this_bug_number>

I've used P-III 550MHz PC under WinNT 4.0 + SP4 to reproduce this 
bug.
Comments
EVALUATION michael.paleczny@eng 2000-02-18 Test passes with current candidate for 2.0 Server VM, running in JDK1.2.2-W Test passes with version of Client from January 28, 2000, running in JDK1.2.2-W. Test passes with Client rc1-S running in JDK1.2.2-W. Failure of this stress test under JDK1.3 duplicates the behaviour of a previous bug: 4256603. In brief, throwing a StackOverflowException is valid when a method contains 64K locals. Stack under 1.3 is 256K. Name: elC94547 Date: 03/17/2000 Indeed, throwing of StackOverflowException would be a valid behaviour. However I believe, that VM crash is not correct behaviour in any case. Please note, that Kestrel does not throw StackOverflowException when trying to execute jck122007, but crashes (java.exe exits with code 128). Such failure looks more severe than #4256603. So, I believe that this bug should be re-open. ======================================================================
11-06-2004