When running under load, the ISV app gets a JVM crash using
JRE1.4.1_02:

Unexpected Signal : 10 occurred at PC=0xFE466BAC
Function=[Unknown. Nearest: AsyncGetCallTrace+0x14DB4]
Library=/opt/intraspect/jre/lib/sparc/server/libjvm.so


Dynamic libraries:
0x10000 /opt/intraspect/jre/bin/Intraspect5OE
0xff350000 /usr/lib/libthread.so.1
0xff390000 /usr/lib/libdl.so.1
0xff200000 /usr/lib/libc.so.1
0xff330000 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
0xfe000000 /opt/intraspect/jre/lib/sparc/server/libjvm.so
0xff2e0000 /usr/lib/libCrun.so.1
0xff1e0000 /usr/lib/libsocket.so.1
0xff100000 /usr/lib/libnsl.so.1
0xff0d0000 /usr/lib/libm.so.1
0xff310000 /usr/lib/libw.so.1
0xff0b0000 /usr/lib/libmp.so.2
0xff080000 /opt/intraspect/jre/lib/sparc/native_threads/libhpi.so
0xff050000 /opt/intraspect/jre/lib/sparc/libverify.so
0xfe7c0000 /opt/intraspect/jre/lib/sparc/libjava.so
0xff030000 /opt/intraspect/jre/lib/sparc/libzip.so
0xfe6d0000 /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
0xca390000 /export/home/oracle/client_app/lib/libocijdbc8.so
0xc7400000 /export/home/oracle/client_app/lib/libclntsh.so.8.0
0xfa010000 /export/home/oracle/client_app/lib/libwtc8.so
0xca2e0000 /usr/lib/libsched.so.1
0xca2c0000 /usr/lib/libgen.so.1
0xca290000 /usr/lib/libaio.so.1
0xca1c0000 /opt/intraspect/jre/lib/sparc/libnet.so
0xca190000 /opt/intraspect/bin/libIKSEventLog.so

Local Time = Tue May 27 14:36:08 2003
Elapsed Time = 1980
#
# HotSpot Virtual Machine Error : 10
# Error ID : 4F530E43505002E6 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.1_02-b06 mixed mode)

Running dbx on the core file shows the signal being thrown at MarkSweep:

(dbx) where
current thread: t@8
=>[1] __sigprocmask(0x0, 0xca1805d8, 0x0, 0x0, 0x0, 0x0), at 0xff369794
  [2] _resetsig(0xff36bf6c, 0x0, 0x0, 0xca181d70, 0xff37e000, 0x0), at 0xff35e9
  [3] _sigon(0xca181d70, 0xff385938, 0x6, 0xca1806ac, 0xca181d70, 0x6), at 0xff
e140
  [4] _thrp_kill(0x0, 0x8, 0x6, 0xff37e000, 0x8, 0xff2be438), at 0xff361180
  [5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff2be3a4, 0x4), at 0xff24b568
  [6] abort(0xff2ba000, 0xca180800, 0x0, 0xfffffff8, 0x4, 0xca180821), at 0xff2
87c
  [7] os::abort(0x1, 0xfe54ce36, 0xca1808a0, 0x0, 0xfe5d0e8c, 0xfe47f17c), at 0
e480a90
  [8] os::handle_unexpected_exception(0x0, 0xa, 0xfe466bac, 0xca1815d8, 0xa, 0x
, at 0xfe47f1ec
  [9] JVM_handle_solaris_signal(0xfe466bac, 0xca1815d8, 0xca181320, 0x4000, 0x4
4, 0x0), at 0xfe1ed234
  [10] __sighndlr(0xa, 0xca1815d8, 0xca181320, 0xfe1ec948, 0xca181e14, 0xca181e
), at 0xff36b830
  [11] sigacthandler(0xa, 0xca181d70, 0x0, 0x0, 0x0, 0xff37e000), at 0xff368508
  ---- called from signal handler with signal 10 (SIGBUS) ------
  [12] MarkSweep::follow_stack(0xfe5cdc30, 0xf7, 0x0, 0x1, 0x0, 0x0), at 0xfe46
ac
  [13] PSMarkSweep::mark_sweep_phase1(0xca181864, 0x0, 0x1, 0x5fbc, 0x4e64, 0x2
10), at 0xfe494c20
  [14] PSMarkSweep::invoke_at_safepoint(0xfe5d21ec, 0xfe5d1614, 0xc7e81434, 0xf
d5a64, 0xfe5d160c, 0x0), at 0xfe4944b0
  [15] PSScavenge::invoke_at_safepoint(0x4c00, 0x4f90, 0x5400, 0x54ac, 0x5400,
5768), at 0xfe498c90
  [16] ParallelScavengeHeap::collect_at_safepoint(0x297f8, 0x1, 0x0, 0xc7e81434
0x4c58, 0xfe247ab0), at 0xfe48847c
  [17] VM_Operation::evaluate(0xc7e81418, 0x0, 0x342b7c, 0xfe5e7fd8, 0xfe5df4c4
0x0), at 0xfe247ab0
  [18] VMThread::evaluate_operation(0x201938, 0xc7e81418, 0x0, 0x29708, 0xfe314
8, 0x0), at 0xfe2474f8
  [19] VMThread::loop(0xfe5db790, 0xfe5d01a4, 0xfe5d01a0, 0x0, 0x0, 0x0), at 0x
3147a4
  [20] VMThread::run(0x201938, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe314374
  [21] _start(0x201938, 0xff37f690, 0x1, 0x1, 0xff37e000, 0x0), at 0xfe280320

I have been able to reproduce this consistently in our lab.

The app is being run using these java options:

-server -Xms700m -Xmx700m -XX:NewRatio=3 -Xloggc:/opt/intraspect/log/gclog -XX:+UseConcMarkSweepGC -XX:+UseParallelGC -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintTenuringDistribution

(these are in there for using GCPortal: -verbose:gc -XX:+PrintGCTimeStamps
-XX:+PrintGCDetails -XX:+PrintTenuringDistribution. The crash happens
without these also.)

The closest similar bug that i've been able to find is 4772715, which
suggests setting -XX:MaxPermSize=128m. I tried this and still got the
crash. I've also tried -client instead of -server and still same crash.
We are not seeing any out of memory errors accompanying this.