JDK-6341414 : reliability tests fail on C1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u3,6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: x86
  • Submitted: 2005-10-25
  • Updated: 2015-02-23
  • Resolved: 2005-11-02
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.
JDK 6
6 b59Fixed
Related Reports
Duplicate :  
Relates :  
Description
Following test crashes
[Enter:javasoft.sqe.tests.lang.clss146.clss14601.clss14601]
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x40279b0b, pid=28751, tid=81931
#
# Java VM: Java HotSpot(TM) Client VM (20051024091129.ni81036.rt_merge compiled mode)
# Problematic frame:
# v  ~RuntimeStub::new_type_array Runtime1 stub

while executing reliability testing, started like this:
java -client -Xcomp -Xbatch  -cp classes runThese -thread 1 -repeat 1 -iter 1 -D:gc=5 -D:TESTBASE=tests -runList runList.dat

gdb backtrace is:
#5  0x062ccd28 in signalHandler(int, siginfo*, void*) ()
#6  0x4002cbc3 in ?? ()
#7  0x40086980 in ?? ()
#8  0x404c66dc in ?? ()
#9  0x404394a0 in ?? ()
#10 0x40227236 in ?? ()
#11 0x061e6dad in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) ()
#12 0x062cd588 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) ()
#13 0x061e6c40 in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) ()
#14 0x062f1dff in Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) ()
#15 0x062f47bc in Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) ()
#16 0x0625004d in JVM_InvokeMethod ()


 Machine it failed on is prt-linux-q2-3.east, libjvm.so which failed is in 
/net/prt-web.east/prt-workspaces/20051024091129.ni81036.rt_merge/linux_i486_compiler1/product/libjvm.so
core file:
/net/prt-web.east/prt-workspaces/20051024091129.ni81036.rt_merge/linux_i486_compiler1/product/runThese_Xcomp_3-reliability-test-product.core

Comments
SUGGESTED FIX http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20051027155100.never.merge/workspace/webrevs/webrev-2005.10.27/index.html
28-10-2005

EVALUATION I think the problem is overflow in the tlab allocation code on intel. TLAB allocation on intel is done by comparing top + size <= end but on sparc it's done by comparing size <=u end - top. If you're sure that top + size never wraps the intel code is ok and normally we guard array allocation with this: const int max_length = 0x00FFFFFF; cmpl(len, max_length); jcc(Assembler::above, slow_case); but the refill logic in the stub does this: // check that array length is small enough for fast path __ cmpl(length, arrayOopDesc::max_array_length(T_DOUBLE)); __ jcc(Assembler::above, slow_path); Before the fix for 5089202 max_array_length was a low enough number that overflow didn't occur but now it's larger than the size of the allocation in this test so it opens us up to the overflow in tlab_allocate. The allocation gets too big and wraps around below the bottom of end. After the allocation the tlab looks like this: start = 0x42307210 top = 0x309b9a20 end = 0x42308978 top = start + round_up(1000000000 * 4 + 12, 8) which actually points outside the heap and death ensues. The fix seems easy which is to make the guards in Runtime1 match the other ones.
26-10-2005