MX & Solaris JVM Memory Crash

[science_of_information]

Have updated MX7 server with newest JAR file (that purports to fix this issue
among other things). So I'm not confident the MX server is ready for deployment
into my production system because of this. Before I start to think MX is
"not-ready-for-primetime" may I ask what you all if there is a work-around/fix
for this issue?

Also - a little off-topic, as I test the environment I find that when I go
home for the night and come back the next day or so the server turns-off(?), or
is crashed. Similar issue?

Thanks.



Pasted Dump messages follow:

Unexpected Signal : 11 occurred at PC=0xFE4B9BBC
Function=sysThreadAvailableStackWithSlack+0x1CD1C
Library=/opt/jrun4/jre/lib/sparc/server/libjvm.so


Dynamic libraries:
0x10000 /opt/jrun4/bin/jrun
0xff380000 /usr/lib/libpthread.so.1
0xff3a0000 /usr/lib/libdl.so.1
0xff280000 /usr/lib/libc.so.1
0xff360000 /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
0xff240000 /usr/lib/libthread.so.1
0xfe000000 /opt/jrun4/jre/lib/sparc/server/libjvm.so
0xff1f0000 /usr/lib/libCrun.so.1
0xff1d0000 /usr/lib/libsocket.so.1
0xff100000 /usr/lib/libnsl.so.1
0xff0d0000 /usr/lib/libm.so.1
0xff1b0000 /usr/lib/libsched.so.1
0xff220000 /usr/lib/libw.so.1
0xff090000 /usr/lib/libmp.so.2
0xff060000 /opt/jrun4/jre/lib/sparc/native_threads/libhpi.so
0xff020000 /opt/jrun4/jre/lib/sparc/libverify.so
0xfe7c0000 /opt/jrun4/jre/lib/sparc/libjava.so
0xfe790000 /opt/jrun4/jre/lib/sparc/libzip.so
0xfc7d0000 /opt/jrun4/jre/lib/sparc/libnet.so
0xfc560000 /opt/jrun4/jre/lib/sparc/librmi.so
0xfbfe0000 /opt/jrun4/jre/lib/sparc/libioser12.so
0xca200000 /opt/jrun4/jre/lib/sparc/libawt.so
0xcd110000 /opt/jrun4/jre/lib/sparc/libmlib_image.so
0xcf2a0000 /opt/jrun4/jre/lib/sparc/headless/libmawt.so

Heap at VM Abort:
Heap
PSYoungGen total 4032K, used 224K [0xd1800000, 0xd1c00000, 0xdc2a0000)
eden space 3968K, 5% used [0xd1800000,0xd18383c0,0xd1be0000)
from space 64K, 0% used [0xd1bf0000,0xd1bf0000,0xd1c00000)
to space 64K, 25% used [0xd1be0000,0xd1be4000,0xd1bf0000)
PSOldGen total 18368K, used 8704K [0xdc2a0000, 0xdd490000, 0xf1800000)
object space 18368K, 47% used [0xdc2a0000,0xdcb20358,0xdd490000)
PSPermGen total 24064K, used 24017K [0xf1800000, 0xf2f80000, 0xf9800000)
object space 24064K, 99% used [0xf1800000,0xf2f746a8,0xf2f80000)

Local Time = Wed Sep 7 14:55:18 2005
Elapsed Time = 12253
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002EF 01
# Please report this error at
# [url]http://java.sun.com/cgi-bin/bugreport.cgi[/url]
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_05-b04 mixed mode)
#
space 3968K, 5% used space 64K, 0% used space 64K, 25% used space 18368K, 47%
used space 24064K, 99% used# An error report file has been saved as
hs_err_pid27138.log.
# Please refer to the file for further information.

(the hs_err_pid*.log replicates the above crash message)

###EOF###

[xentrix]

The error you're experiencing is a JVM issue rather than a ColdFusion issue.

There's a number of things you can try - having scowered the Sun bug parade -
to try and fix the problem.

1) Upgrade to the latest (supported) JCM, which is 1.4.2_09
2) Use the -Xint argument (gives slower performance)
3) Set your Min/Max Heap sizes to be identical
4) Switch JVM to either IBMs or BEAs
5) Possible hardware issue - faulty memory can also cause this issue.

No promises that any of the above will actually help, but they are options for
you to try.

Andy

[science_of_information]

I've been hammering on the environment with the most intensive op's I can think
of and cannot crash the binary. At this point I'm thankfully but tentatively
calling xentrix' suggestion for JVM upgrade as a solid step toward stability.

Summary: (Solaris) Updated JVM (Sun v. 1.4.2_09), don't forget to update
jvm.config file to reflect new jvm location (per Forta). Restarted jrun with
new JVM.

Thanks!