JDK-4451928 : HS1.4(sparc): 32-bit server crashed by nsk/stress/except/except001
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_2.6,solaris_8
  • CPU: sparc
  • Submitted: 2001-04-27
  • Updated: 2001-12-11
  • Resolved: 2001-06-05
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 beta2Fixed
Related Reports
Duplicate :  
JDK-4461721 - nsk/stress/except/except011 test dumps core.
Relates :  
JDK-4428861 - java.lang.reflect.Method.invoke() throws incorrect exceptions
Description

Name: elR10090			Date: 04/27/2001


JDK 1.4 (sparc) 32-bit server VM builds -b59 to -b61 crash when executed 
against the stress tests "nsk/stress/except/..." (12 tests totaly).  
Following is typical crash log:

    >>>> javac except001.java
    >>>> time java -server except001 ; echo $status
    # While printing this message, JVM seems to initiate the output
    # stream, so that it will not need more memory to print later,
    # when the heap would fail to provide more memory.
    # 
    # That problem is caused by the known JDK/HotSpot bugs:
    #     4239841 (P1/S5) 1.1: poor garbage collector performance
    #     4245060 (P4/S5) poor garbage collector performance
    # 
    # This message is just intended to work-around that problem.
    # If printing should fail even so.
    
    Unexpected Signal : 11 occurred at PC=0xFE0F33C4
    Function=JVM_ReleaseUTF+0xEB0
    Library=/export/ld54/java/dest/jdk1.4.0beta-b61/solsparc/jre/lib/sparc/server/libjvm.so
    
    Current Java thread:
    Segmentation Fault
    1.0u 0.0s 0:03 28% 0+0k 0+0io 0pf+0w
    139

Earlier builds of HS do not crash against "except001"; though they 
fail due to the known bug:
        4428861 java.lang.reflect.Method.invoke() throws incorrect exceptions
(such failure probably masks the crash).

To reproduce the crash, please try "doit.sh" script found in the 
directory:
    /net/sqesvr.eng/export/vsn/GammaBase/Bugs/<this_Bug_ID>
Use it like:
    sh doit.sh $JAVA_HOME

Please note, that the tests except001, ..., except012 were recently 
fixed accordingly to the bug:
    4433087 TEST_BUG: 12 stress tests should be ajusted to 64-bit JDK
 
The test version provided with GammaBase is the fixed one; and the 
fixed versions will appear in "testbase_nsk.v14r04" soon under the 
following directory:
    /net/sqesvr.eng/export/vsn/VM/testbase/testbase_nsk.v14r04

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

Name: elR10090			Date: 05/21/2001



Ivan Popov (###@###.###)

Here is full names of the tests failed against merlin-b65
due to this bug:

nsk/stress/except/except001
nsk/stress/except/except002
nsk/stress/except/except003
nsk/stress/except/except004
nsk/stress/except/except005
nsk/stress/except/except006
nsk/stress/except/except007
nsk/stress/except/except008
nsk/stress/except/except009
nsk/stress/except/except010
nsk/stress/except/except011
nsk/stress/except/except012


======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2 VERIFIED IN: merlin-rc1
14-06-2004
EVALUATION Ran debug version build 62 and this is the stack trace I got. It appears that the vm is trying to allocate an array of 2^32nd size and fails. This testcase works with client. Changing for loop from for (int size=1<<30; size>0 && pool==null; size>>=1 ) to for (int size=1<<25; size>0 && pool==null; size>>=1 ) will allow the test to work on both server and client, changing testcase should NOT be the fix. =>[1] _libc_read(0x0, 0xff2bf624, 0x400, 0xff382188, 0xff2bc478, 0xff00), at 0xff29a740 [2] __filbuf(0xff2bc2c4, 0xff2bfa24, 0xff2b800c, 0x0, 0x400, 0x0), at 0xff28afd8 [3] fgets(0xff2bfa8c, 0xff2bbc88, 0xff2bc2c4, 0xff2b800c, 0xff2bfa24, 0x3ff), at 0xff28d820 [4] os::message_box(0xffbec054, 0xfe193f00, 0xb, 0xfd74b140, 0xb, 0x0), at 0xfd9c45d0 [5] os::handle_unexpected_exception(0x3aa88, 0xb, 0xfd74b140, 0xffbeceb8, 0xb, 0x0), at 0xfd9b20d0 [6] JVM_handle_solaris_signal(0xb, 0xffbeceb8, 0xffbecc00, 0x1, 0x0, 0x0), at 0xfd9d0d28 [7] signalHandler(0xb, 0xffbeceb8, 0xffbecc00, 0xff37e000, 0x25df0, 0x25de0), at 0xfd9c47c4 [8] __libthread_segvhdlr(0xb, 0xffbeceb8, 0xffbecc00, 0xff37e000, 0xb, 0x0), at 0xff369124 [9] __sighndlr(0xb, 0xffbeceb8, 0xffbecc00, 0xff369040, 0x25df0, 0x25de0), at 0xff36bc94 [10] sigacthandler(0xb, 0x25d58, 0xffbecc00, 0xff37e000, 0x25d58, 0xffbeceb8), at 0xff368498 ---- called from signal handler with signal 11 (SIGSEGV) ------ [11] Memory::pd_set_words(0xf1435a50, 0x10000004, 0x0, 0x3aa88, 0x0, 0x1), at 0xfd74b140 [12] Memory::set_words(0xf1435a50, 0x10000004, 0x0, 0x3aa88, 0x0, 0xffbed360), at 0xfd74aef4 [13] CollectedHeap::allocate_from_tlab(0x3aa88, 0x10000004, 0x3aa88, 0x1, 0x17f, 0xffbed420), at 0xfd74a4d8 [14] CollectedHeap::common_mem_allocate_noinit(0x10000004, 0x3aa88, 0x1, 0x3aa88, 0x0, 0x0), at 0xfd749a84 [15] CollectedHeap::common_mem_allocate_init(0x10000004, 0x3aa88, 0x1, 0x3aa88, 0xfffffff8, 0x3b038), at 0xfd747860 [16] CollectedHeap::array_allocate(0xffbed248, 0x10000004, 0x10000000, 0x3aa88, 0xfffffff8, 0x3b4b8), at 0xfd744458 [17] instanceKlass::allocate_objArray(0xf5403ac8, 0x1, 0x10000000, 0x3aa88, 0x25df0, 0x25de0), at 0xfd73b86c [18] oopFactory::new_objArray(0xf5403ac0, 0x10000000, 0x3aa88, 0x1, 0x3aa88, 0x1), at 0xfd998fd0 [19] InterpreterRuntime::anewarray(0x3aa88, 0xf54e8640, 0x13, 0x10000000, 0x0, 0x1), at 0xfd78a090 [20] 0xf98277e8(0xdead0000, 0xdead0002, 0x0, 0xf9819d64, 0x0, 0xffbed360), at 0xf98277e7 [21] 0xf9800518(0xffbed508, 0xffbed800, 0xa, 0xf54e9150, 0x0, 0xffbed420), at 0xf9800517 [22] JavaCalls::call_helper(0xffbed810, 0xf98004a0, 0xffbed808, 0x3aa88, 0x0, 0x0), at 0xfd7ccf60 [23] os::os_exception_wrapper(0xfd7cc980, 0xffbed7f8, 0xffbed78c, 0xffbed808, 0x3aa88, 0x0), at 0xfd9c46b4 [24] JavaCalls::call(0xffbed7f8, 0xffbed78c, 0xffbed808, 0x3aa88, 0x0, 0x0), at 0xfd7cc910 [25] Reflection::invoke(0xffbed8fc, 0xffbed8f8, 0xffbed8f4, 0x0, 0xffbed8f0, 0xe), at 0xfd9eca98 [26] Reflection::invoke_method(0xffbed8ec, 0x1, 0xffbed9bc, 0x3aa88, 0x0, 0x0), at 0xfd9ee52c [27] JVM_InvokeMethod(0x3ab1c, 0xffbedaf8, 0x0, 0xffbedb00, 0xffbed8c8, 0x1), at 0xfd851ba8 [28] Java_sun_reflect_NativeMethodAccessorImpl_invoke0(0x3ab1c, 0xffbedaf4, 0xffbedaf8, 0x0, 0xffbedb00, 0xffbed96c), at 0xfe7caa7c [29] 0xf991411c(0xf1435a38, 0xf1434368, 0x0, 0xf14358a0, 0x3aa88, 0x0), at 0xf991411b [30] 0xf991338c(0xf1435a38, 0x0, 0xf14358a0, 0x5, 0x0, 0x3aa88), at 0xf991338 gary.collins@East 2001-05-01 karen.kinnear@East 2001-05-22 Problem with large number wrapping in check to see if new size fits in TLABS. Fix lost from collectedHeap.inline.hpp. Same fix also needed in collectedHeap.cpp. Code was: top + size <= end New code: assert top < end end - top >= size Rest of runtime, memory, utilities, debug checked for same problem.
11-06-2004