|
Quick Lists
|
|
Bug ID:
|
6642634
|
|
Votes
|
0
|
|
Synopsis
|
Test nsk/regression/b6186200 crashed with SIGSEGV
|
|
Category
|
hotspot:garbage_collector
|
|
Reported Against
|
b02
, b14
|
|
Release Fixed
|
hs12(b02)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
6431128
,
6574315
,
6583391
,
6588423
,
6590196
,
6605622
,
6611406
|
|
Submit Date
|
17-DEC-2007
|
|
Description
|
Test nsk/regression/b6186200 crashed with 6u4p-b02 during promotion testing on solaris-sparcv9 bits.
Results are available here
http://sqeweb.sfbay/nfs/tools/gtee/results/JDK_PERFORMANCE/PROMOTION/VM/6u4p/b02/CMS/2007-12-14/vm/64BITSOLSPARC5.10/server/mixed/vm-64BITSOLSPARC5.10_server_mixed_nsk.regression.testlist2007-12-14-12-52-21/analysis.html
or here
/net/sqenfs-1.sfbay/export1/tools/gtee/results/JDK_PERFORMANCE/PROMOTION/VM/6u4p/b02/CMS/2007-12-14/vm/64BITSOLSPARC5.10/server/mixed/vm-64BITSOLSPARC5.10_server_mixed_nsk.regression.testlist2007-12-14-12-52-21
This failure reproduce permanently with all current trains 6u4p/6u4/7.
Hss_err file:
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xffffffff7dfac208, pid=28359, tid=3
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b09 mixed mode solaris-sparc)
# Problematic frame:
# V [libjvm.so+0x3ac208]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x0000000100132400): ConcurrentGCThread [stack: 0xffffffff6c600000,0xffffffff6c700000] [id=3]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000018
Registers:
O0=0x0000000000042000 O1=0xffffffff72218868 O2=0x0000000000000000 O3=0x0000000000000000
O4=0x0000000000000000 O5=0x0000000000000001 O6=0xffffffff6c6fead1 O7=0xffffffff7dfac0d0
G1=0x0000000000042d50 G2=0x0000000000000000 G3=0xffffffff7e5f5630 G4=0x0000000000000001
G5=0xffffffff7e5ae000 G6=0x0000000000000000 G7=0xffffffff6c500000 Y=0x0000000000000000
PC=0xffffffff7dfac208 nPC=0xffffffff7dfac20c
Top of Stack: (sp=0xffffffff6c6ff2d0)
0xffffffff6c6ff2d0: 0000000000000001 ffffffff6d100000
0xffffffff6c6ff2e0: 00000000000ecc00 000000000001d980
0xffffffff6c6ff2f0: 0000000000766000 0000000000766000
0xffffffff6c6ff300: 0000000003b30000 0000000100131c00
0xffffffff6c6ff310: ffffffff6c6ff570 ffffffff723f0000
0xffffffff6c6ff320: ffffffff6c6ff570 0000000000000000
0xffffffff6c6ff330: 0000000000000000 ffffffff7e5f0d50
0xffffffff6c6ff340: ffffffff6c6feb81 ffffffff7df8245c
0xffffffff6c6ff350: 0000000000000000 0000000000298000
0xffffffff6c6ff360: ffffffff73cc0000 0000000000000000
0xffffffff6c6ff370: 0000000100131d40 0000000100131e60
0xffffffff6c6ff380: ffffffff7e5d9b78 ffffffff7df2ce70
0xffffffff6c6ff390: ffffffff7e5daf38 ffffffff6c6ff418
0xffffffff6c6ff3a0: 0000000000000000 ffffffff7e5ae000
0xffffffff6c6ff3b0: ffffffff723f0000 00000000001d7798
0xffffffff6c6ff3c0: 000000010011c170 ffffffff6c6ff570
Instructions: (pc=0xffffffff7dfac208)
0xffffffff7dfac1f8: 00 00 00 00 00 00 00 00 9d e3 bf 50 c4 customer 60 08
0xffffffff7dfac208: c2 00 a0 18 80 a0 60 00 14 40 00 1a 91 38 60 03
Stack: [0xffffffff6c600000,0xffffffff6c700000], sp=0xffffffff6c6ff2d0, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x3ac208]
V [libjvm.so+0x382464]
V [libjvm.so+0x3a7058]
V [libjvm.so+0x3a66ac]
V [libjvm.so+0x39c2e4]
V [libjvm.so+0x3b0588]
V [libjvm.so+0x638cdc]
...
Posted Date : 2007-12-17 14:04:54.0
|
|
Work Around
|
Fixing the size of the old generation (or the entire heap via
-Xmx == -Xms) and of the perm gen (via -XX:PermSize == -XX:MaxPermSize)
appears to be a good workaround since the bug is in the expand_and_allocate() path.
|
|
Evaluation
|
This appears to be a bug in the product at least since 2002 as far
as i can tell, where we are not careful to deal with direct allocation
following an expansion when a CMS cycle is in progress. It is not yet
clear why the bug is difficult to reproduce once we use ParNew.
See the workaround section for a workaround. The "Suggested Fix"
section will be updated with a fix over the next few days.
A bit more archeology is in progress, but it appears as though
all current versions of the JDK going all the way back to 1.4.2
would be vulnerable to this problem.
Watch this space for further updates soon.
Posted Date : 2008-01-02 19:20:28.0
Fix putback to hotspot-gc; see comments section and suggested fix section
for jprt id and comment.
Posted Date : 2008-02-21 21:35:11.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |