JDK-6390242 : jdk1.5.0_06 jvm dumps running client load for specweb2005 banking on t2000
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0u6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_nevada
  • CPU: sparc
  • Submitted: 2006-02-24
  • Updated: 2011-05-25
  • Resolved: 2006-12-19
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
5.0u6 b05Fixed
Related Reports
Relates :  
Description
Running the specweb2005_banking benchmark using a t2000 machine as a client,
the client machine's jvm repeatedly crashes 

The jvm is question is jdk1.5.0_06. Relinking to j2sdk1.4.2_10 runs the benchmark client load without issue. The following is the error dumped from the jvm:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGBUS (0xa) at pc=0xf9015db4, pid=385, tid=175
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b04 mixed mode)
# Problematic frame:
# j  java.lang.AbstractStringBuilder.append(Ljava/lang/String;)Ljava/lang/AbstractStringBuilder;+8
#

---------------  T H R E A D  ---------------

Current thread (0x006cee18):  JavaThread "Thread-121" daemon [_thread_in_Java, id=175]

siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x005f0046

Registers:
 O0=0x005f0046 O1=0x000000b6 O2=0x00001757 O3=0x43fdef8e
 O4=0xec714ea0 O5=0x00000000 O6=0xb7a7f578 O7=0xf90ec1b8
 G1=0xffffff78 G2=0x006cee18 G3=0xc28a77f0 G4=0x00000004
 G5=0xc2808960 G6=0x00000000 G7=0xf8fba000 Y=0x00000000
 PC=0xf9015db4 nPC=0xf9015db8


Top of Stack: (sp=0xb7a7f578)
0xb7a7f578:   b7a7f5e0 c2851930 c2851978 b7a7f64c
0xb7a7f588:   b7a7f5e8 3c800001 c28a7600 006cee18
0xb7a7f598:   e8a160e0 e99f62f0 c2c9bc60 f9015cc0
0xb7a7f5a8:   e99f62f0 b7a7f608 b7a7f600 f904f0b8
0xb7a7f5b8:   00000000 00423878 ec5e4088 006cee18
0xb7a7f5c8:   ec5e4088 005f0046 00000000 ec5e4088
0xb7a7f5d8:   000053e4 006cee18 ec5e4088 005f0046
0xb7a7f5e8:   43fdef8e 43fdef8e ec714ea0 43fdda70

Instructions: (pc=0xf9015db4)
0xf9015da4:   88 0d 60 ff c8 11 60 26 89 29 20 02 d0 04 00 04
0xf9015db4:   c0 02 20 00 80 90 00 1a 02 40 00 07 01 00 00 00

Stack: [0xb7a00000,0xb7a80000),  sp=0xb7a7f578,  free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
j  java.lang.AbstractStringBuilder.append(Ljava/lang/String;)Ljava/lang/AbstractStringBuilder;+8
v  ~C2IAdapter
J  org.spec.specweb.SPECweb_Banking.buildRequest(Ljava/lang/StringBuffer;I)Ljava/lang/String;
v  ~I2CAdapter
j  org.spec.specweb.SPECweb_Banking.makeRequest(II)Z+498
j  org.spec.specweb.WorkloadScheduler.threadAction()V+76
j  org.spec.specweb.WorkloadScheduler$1.run()V+4
v  ~StubRoutines::call_stub
V  [libjvm.so+0x199bd0]
V  [libjvm.so+0x2c2564]
V  [libjvm.so+0x2e1ac8]
V  [libjvm.so+0x2dd664]
V  [libjvm.so+0x662d98]

The remainder of the file is attached to this bug.
This happened repeatedly for multiple executions of the benchmark client.

The core dumped is available at:

/net/irperf.ireland/export/work/crash_images/Fri.Feb24.2006.oaf274.specweb2005_banking.snv_30
irperf# ls -l
total 16768
-rw-r--r--   1 root     other    8571952 Feb 24 17:06 core.java.385.1140715061.gz

Comments
EVALUATION 5.0u6 b05 delivered into snv_37, which should resolve this issue for Nevada.
28-03-2006

EVALUATION I can confirm that using the above jvm the dump is not reproducible and the specweb2005 workload runs in entirity. It seems the cause of this problem is indeed that nevada is producing its builds with the weekly build of the jvm that has not been updated in some time, i.e. snv_30 and snv_35 are both using the same weekly jvm.
24-03-2006