Re: Java 1.5_22 crash my server, please for help
Sherkan wrote, quoted or indirectly quoted someone who said :
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0xb7962d4f, pid=3307, tid=1355598736
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_22-b03 mixed mode)
# Problematic frame:
# V [libjvm.so+0x402d4f]
Roedy Green wrote:
This sounds like the sort of thing only Sun can fix.
However, if this happens after only a few days, it could be some sort
of slow memory leak. Is there a way you could monitor free memory to
see if is gradually reducing?
SIGSEGV is not usually a result of a slow memory leak. It's an illegal access
to a section of memory, in this case by the JVM itself. Monitoring free
memory as seen by the application itself probably won't help, and I really
can't see how monitoring free memory in the OS would help either.
If the problem were a memory leak or insufficient memory allocated to the
heap, you wouldn't get a SIGSEGV.
The problem is nearly impossible to diagnose from Usenet, although if we knew
the code layout of libjvm.so and had source we could probably figure out which
instruction was trying to access memory illegally.
Sherkan wrote:
Next time make it easier to read this by formatting it for Usenet. It's hard
to follow all these complicated options when line breaks interrupt in the
middle of an argument. (I tried to neaten up here for citation.)
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m
-XX:MinHeapFreeRatio=40 -XX:MaxHeapFreeRatio=70 -XX:NewRatio=3
-XX:MaxNewSize=512m
Some interesting choices here for your JVM arguments. Why these values? In
particular, aren't 40 an 70 the default values for the min and max HeapFreeRatios?
-Dsun.rmi.dgc.server.gcInterval=3600000 -XX:+UseParNewGC
-XX:+CMSPermGenSweepingEnabled
-XX:+ClassUnloading -XX:+CMSClassUnloadingEnabled
-XX:CompileThreshold=100 -XX:CompileThreshold=100
Why is CompileThreshold here twice? Or at all?
-XX:+PrintGCDetails -verbose:gc -Xloggc:/serwer/jvm
"serwer" is an interesting spelling.
-Djava.util.logging.config.file=/serwer/tomcat6/conf/logging.properties
-Djava.endorsed.dirs=/serwer/tomcat6/endorsed
-Dcatalina.base=/serwer/tomcat6 -Dcatalina.home=/serwer/tomcat6
You don't actually need to specify $CATALINA_BASE if it's the same as
$CATALINA_HOME.
-Djava.io.tmpdir=/serwer/tomcat6/temp
Moving on:
Environment Variables:
LD_LIBRARY_PATH=/serwer/install/jdk1.5.0_22/jre/lib/i386/server:
/serwer/install/jdk1.5.0_22/jre/lib/i386:
/serwer/install/jdk1.5.0_22/jre/../lib/i386
I don't see the relevance of LD_LIBRARY_PATH. That's something for C
programs, not Java. Are you using JNI? If so, why, in a Tomcat context?
2 days ago I had java [sic] newest java 1.6 with same problem.
I get still this message:
# Problematic frame:
# V [libjvm.so+0x402d4f]
(Line wrap fixed up - you really need to manage that.)
Somehow that's just waaaaay too much of a coincidence. You might be accessing
the wrong libjvm.so.
--
Lew