Customer encounters crash in ConcurrentMarkSweepThread when using CMS.
(dbx) where -l
  [1] libthread.so.1:__sigprocmask(0x3, 0xdc240444, 0x0), at 0xdfb66b94
  [2] libthread.so.1:_resetsig(0x0, 0x6, 0xdfb7a000, 0x0, 0x1, 0xdc240d00), at 0xdfb5d9d4
  [3] libthread.so.1:_sigon(0xdfb7a000, 0xdc2404a0, 0xdfb5f953, 0xdfb812f8, 0x6, 0x6), at 0xdfb5d2fd
  [4] libthread.so.1:_lmutex_unlock(0xdfb812f8), at 0xdfb5ac70
  [5] libthread.so.1:_thrp_kill(0xdc240d68, 0x6, 0x6, 0xdef9808d, 0xdefe08c4, 0xdfb35000), at 0xdfb5f953
  [6] libthread.so.1:_pthread_kill(0x6, 0x6), at 0xdfb5f843
  [7] libc.so.1:raise(0x6), at 0xdfadbd87
  [8] libc.so.1:abort(0xdefc8000, 0xdc2405c0, 0xdef39955, 0x1, 0x0, 0x0), at 0xdfacc14c
  [9] libjvm.so:os::abort(0x1), at 0xdeeec4ff
  [10] libjvm.so:VMError::report_and_die(0xdc2405d8, 0xdc2407bc, 0xdc240d68, 0xdefc8000, 0xb, 0xdef98562), at 0xdef39955
  [11] libjvm.so:JVM_handle_solaris_signal(0xb, 0xdc240a3c, 0xdc24083c, 0x1), at 0xdedd284b
  [12] libjvm.so:signalHandler(0xb, 0xdc240a3c, 0xdc24083c, 0xdc240828, 0xdfb65b55, 0xb), at 0xdedd20a0
  [13] libthread.so.1:__sighndlr(0xb, 0xdc240a3c, 0xdc24083c, 0xdedd2080), at 0xdfb57a8b
  ---- called from signal handler with signal 11 (SIGSEGV) ------
=>[14] libjvm.so:MarkFromRootsClosure::scanOopsInOop(0xdc240b70, 0xcb6519e8), at 0xdee17915
  [15] libjvm.so:MarkFromRootsClosure::do_bit(0xdc240b70, 0x89467a), at 0xdee1770b
  [16] libjvm.so:BitMap::iterate(0x8128bd4, 0xdc240b70, 0x0, 0x3f00000), at 0xdeddbf48
  [17] libjvm.so:CMSCollector::markFromRootsWork(0x8128b60, 0x1), at 0xdee12c79
  [18] libjvm.so:CMSCollector::markFromRoots(0x8128b60, 0x1), at 0xdee12ab7
  [19] libjvm.so:CMSCollector::collect_in_background(0x8128b60, 0x0), at 0xdee10c7c
  [20] libjvm.so:ConcurrentMarkSweepThread::run(0x8139060), at 0xdee1a2de
  [21] libjvm.so:_start(0x8139060, 0xdeeec230), at 0xdeeec302

The heap shows

Heap
 par new generation total 347328K, used 190482K [0xb4000000, 0xc9400000, 0xc9400000)
  eden space 346496K, 54% used [0xb4000000, 0xbfa04b78, 0xc9260000)
  from space 832K, 0% used [0xc9330000, 0xc9330000, 0xc9400000)
  to space 832K, 0% used [0xc9260000, 0xc9260000, 0xc9330000)
 concurrent mark-sweep generation total 176128K, used 43830K [0xc9400000, 0xd4000000, 0xd4000000)
 concurrent-mark-sweep perm gen total 81920K, used 38705K [0xd4000000, 0xd9000000, 0xd9000000)

jvm_args: -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -Xms512m -Xmx512m -verbose:gc -XX:+PrintGCTimeStamps -XX:PermSize=80m -XX:MaxPermSize=80m -XX:NewSize=340m -XX:MaxNewSize=340m -XX:SoftRefLRUPolicyMSPerMB=125 -XX:SurvivorRatio=400


###@###.### 2005-04-29 05:30:31 GMT
In Nokia we have seen a similar problem using Java 5:


Anyone any ideas why our jvm server crashed with the following stack trace ?
This is a Weblogic process, running version 9 of WL on Solaris 9 sparc.
The crashed happened in QA not PROD env.

Is this a crash from the CMS collector ? If the problem reoccurs I will open a CR.
There are no test cases which can reproduce the crash.

Many thanks,
Stefan


#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGBUS (0xa) at pc=0xfec282d8, pid=9234, tid=6
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_09-b03 mixed mode)
# Problematic frame:
# V [libjvm.so+0x4282d8]
#

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

Current thread (0x00125410): ConcurrentMarkSweepThread [id=6]

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

Registers:
 O0=0x00000000 O1=0xc108c560 O2=0xfb17f8b4 O3=0x00000002
 O4=0x00000009 O5=0x00104f44 O6=0xfb17f850 O7=0x000038f0
 G1=0x000038f0 G2=0x61980000 G3=0x0000e3bc G4=0x000038ef
 G5=0x00000000 G6=0x00000000 G7=0xff350a00 Y=0x00000000
 PC=0xfec282d8 nPC=0xfec282dc


Top of Stack: (sp=0xfb17f850)
0xfb17f850: fb17f8b4 00000001 0069006f 00008000
0xfb17f860: feed26a8 00007000 ffffffff ff0171b4
0xfb17f870: fb17fa30 00009118 ff01407c ff014080
0xfb17f880: ff0174fc fefce000 fb17f8e0 febe40fc
0xfb17f890: 00000000 001258bc fb17f948 fec22f48
0xfb17f8a0: fb17f8c8 fb17f900 00000000 00000001
0xfb17f8b0: 00000001 ff013fb0 001b50b0 00104e50
0xfb17f8c0: 90c00000 1a000000 00104e84 00104f44

Instructions: (pc=0xfec282d8)
0xfec282c8: c8 23 60 3c 87 29 20 02 d2 00 80 03 e4 02 60 04
0xfec282d8: d6 04 a0 08 e8 02 e0 d0 9f c5 00 00 90 04 a0 08

Stack: [0xfb100000,0xfb180000), sp=0xfb17f850, free space=510k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x4282d8]
V [libjvm.so+0x3e4104]
V [libjvm.so+0x421864]
V [libjvm.so+0x4215a4]
V [libjvm.so+0x41ee58]
V [libjvm.so+0x42bf2c]
V [libjvm.so+0x670740]


The thread 6 died. Its stack trace is below:
tid 6 died. Analyzing the core dump looks like
the CMS might be the problem here. Im not sure. It could be a
problem between CMS and the VM.

----------------- t@6 -----------------
0xff31fc54 _lwp_kill + 0x8
0xff2b6d50 abort + 0x100
0xfee70c1c void os::abort(int) + 0x58
0xfeeff200 void VMError::report_and_die() + 0xc84
0xfea73480 JVM_handle_solaris_signal + 0xaac
0xff385bac __sighndlr + 0xc
0xff37f804 call_user_handler + 0x234
0xff37f9b4 sigacthandler + 0x64
0xfec282d8 void MarkFromRootsClosure::scanOopsInOop(HeapWord*) + 0x174
0xfebe40fc void BitMap::iterate(BitMapClosure*,unsigned,unsigned) + 0x80
0xfec2185c int CMSCollector::markFromRootsWork(int) + 0x168
0xfec2159c int CMSCollector::markFromRoots(int) + 0x134
0xfec1ee50 void CMSCollector::collect_in_background(int) + 0x2d0
0xfec2bf24 void ConcurrentMarkSweepThread::run() + 0x4fc
0xfee70738 void*_start(void*) + 0x208
0xff385854 _lwp_start


Our VM options:


Other Threads:
  0x001b5bd8 VMThread [id=7]
  0x001cad68 WatcherThread [id=16]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 par new generation total 523840K, used 299620K [0x70c00000, 0x90c00000, 0x90c00000)
  eden space 523392K, 57% used [0x70c00000, 0x83099360, 0x90b20000)
  from space 448K, 0% used [0x90b20000, 0x90b20000, 0x90b90000)
  to space 448K, 0% used [0x90b90000, 0x90b90000, 0x90c00000)
 concurrent mark-sweep generation total 1572864K, used 1040001K [0x90c00000, 0xf0c00000, 0xf0c00000)
 concurrent-mark-sweep perm gen total 131072K, used 74795K [0xf0c00000, 0xf8c00000, 0xf8c00000)


VM Arguments:
jvm_args: -XX:+UseConcMarkSweepGC -Xms2048m -Xmx2048m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:PermSize=128m -XX:MaxPermSize=128m -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 -Dcommerce.properties=/opt/nokiacif/app/swd/current/config/swdDomain/properties/weblogiccommerce.properties -DmasterReference=/opt/nok
iacif/app/swd/current/config/swdDomain/properties/master.properties -Djava.awt.headless=true -Dweblogic.Name=swdServer2 -Dbea.home=/opt/nokiacif/bea9 -Dweblogic.man
agement.username=system -Dweblogic.management.password=weblogic -Dweblogic.ProductionModeEnabled=true -Dweblogic.management.discover=true -Djavax.xml.soap.MessageFa
ctory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl -Dweblogic.management.server=wl-swd-admin:7110 -Djava.security.policy=/opt/nokiacif/bea9/webl
ogic91/server/lib/weblogic.policy
java_command: weblogic.Server
Launcher Type: SUN_STANDARD

Environment Variables:
CLASSPATH=/opt/nokiacif/app/swd/current/config/swdDomain/autodeploy/FDPNotify/WEB-INF/lib/saaj.jar:/opt/nokiacif/bea9/weblogic91/server/lib/weblogic.jar:/opt/nokiac
if/bea9/weblogic91/server/lib/webservices.jar::/opt/nokiacif/bea9/jdk1.5.0_09/lib/tools.jar:::/opt/nokiacif/app/swd/current/config/swdDomain/autodeploy/SWD/APP-INF/
lib/NCP.jar:/opt/nokiacif/app/swd/current/config/swdDomain/autodeploy/SWD/APP-INF/lib/nols_common.jar:/opt/nokiacif/app/swd/current/config/swdDomain/autodeploy/SWD/
APP-INF/lib/commons-lang-2.1.jar:/opt/nokiacif/app/swd/current/config/swdDomain/autodeploy/SWD/APP-INF/lib/commons-httpclient-2.0.jar:/opt/nokiacif/bea9/weblogic91/
server/lib/consoleapp/APP-INF/lib/commons-logging.jar:/opt/nokiacif/app/swd/current/config/swdDomain/autodeploy/SWD/APP-INF/lib/jdom.jar:/opt/nokiacif/bea9/weblogic
91/server/lib/consoleapp/APP-INF/lib/log4j.jar
PATH=/opt/nokiacif/bea9/weblogic91/server/bin/oci920_8:/opt/nokiacif/bea9/weblogic91/server/bin:/opt/nokiacif/bea9/jdk1.5.0_09/bin:/usr/bin::/opt/stlbox/bin:/usr/lo
cal/bin:/usr/ucb/bin:/opt/misctool/openssh/bin:/opt/misctool/sudo/bin
LD_LIBRARY_PATH=/opt/nokiacif/bea9/jdk1.5.0_09/jre/lib/sparc/server:/opt/nokiacif/bea9/jdk1.5.0_09/jre/lib/sparc:/opt/nokiacif/bea9/jdk1.5.0_09/jre/../lib/sparc:/op
t/nokiacif/bea9/weblogic91/server/lib/solaris:/opt/nokiacif/bea9/weblogic91/server/lib/solaris/oci920_8
SHELL=/bin/ksh
HOSTTYPE=sparc
OSTYPE=solaris2.9
MACHTYPE=sparc-sun-solaris2.9

Signal Handlers:
SIGSEGV: [libjvm.so+0x6ff5b8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGBUS: [libjvm.so+0x6ff5b8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGFPE: [libjvm.so+0x27299c], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x27299c], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x27299c], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGUSR1: [libjvm.so+0x672ca4], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIGUSR2: [libjvm.so+0x27299c], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGHUP: [libjvm.so+0x67191c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGINT: [libjvm.so+0x67191c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGQUIT: [libjvm.so+0x67191c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0x67191c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004


--------------- S Y S T E M ---------------

OS: Solaris 9 9/04 s9s_u7wos_09 SPARC
           Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 29 June 2004

uname:SunOS 5.9 Generic_118558-30 sun4u (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 8192, AS infinity
load average:0.71 0.19 0.09

CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3

Memory: 8k page, physical 16777216k(10392456k free)

vm_info: Java HotSpot(TM) Server VM (1.5.0_09-b03) for solaris-sparc, built on Oct 12 2006 01:30:08 by unknown with unknown Workshop:0x550
Another customer (Intralinks) has run into the same issue with Java 5.
Actually, they see it with a 5.0u11-based FVB for CR 6492085 and
CR 6518092 provided by Java sustaining. We found no connection of
the newly observed crash to the original fix.

I recommended to use -XX:-CMSParallelRemarkEnabled option as a workaround
and asked to try to reproduce the crash with fastdebug version and
-Verify{Before,After,During}GC options specified.