Tomcat/Java Compiler crash

Question

The following issue is running on a HP/UX 11i V2 Itanium Superdome server.
We have a vendor application being deployed with Tomcat. The versions of Tomcat and java are:
Tomcat is 5.0.28 (required by vendor)
java is 1.4.2.10 (required by vendor)
Tomcat is randomly crashing with the following:
SIGSEGV 11* segmentation violation
si_signo [11]: SIGSEGV 11* segmentation violation
si_errno [0]: Error 0
si_code [2]: SEGV_ACCERR [addr: 0xc00]
Aborting...
Unexpected Signal : 11 occurred at PC=0xC56EF780
Function=_ZN7RegMask3ANDERKS_
Compiler thread crashed while compiling a method!
Compiled method class=ibi.broker.util.RCDES
Compiled method name=getStringFromHexString
Compiled method signature=(Ljava/lang/String;)Ljava/lang/String;
Library=/opt/java1.4/jre/lib/IA64N/server/libjvm.so
Current Java thread:
"CompilerThread0" daemon prio=7 tid=00064c50 nid=9 lwp_id=3017 runnable [0x00000
000..0x6a4001f8]
This is a problem with java compiling a method out of a class/jar file, correct? So, I added the following directive in the catalina.sh file for the JAVA_OPTS:
-XX:CompileCommand= exclude,ibi/broker/util/RCDES,getStringFromHexString
This should prevent the suspect method from getting compiled. And it does. The catalina.out file has
### Excluding compile: ibi.broker.util.RCDES::getStringFromHexString
which verifies this.
Well, then vendor thinks this is a problem with either Tomcat or Java.
So, does anyone think this is really a Tomcat or Java problem or a problem with the vendors method? I was able to find the jar file with the class file that contains this method. Since this is in a class file, is there a way to manually compile this method to see if I can reproduce the problem?

Answer 1

The JVM should never segfault. Unless you are using JNI it shouldn't be possible to write code that causes this sort of behaviour.
So when you see a segfault it usually boils down to (in no particular order) one of:
1. Hardware problem
2. JNI (mis)use
3. JVM bug.
Check with the vendor to see if their app includes any JNI logic. If not, try it on known good hardware. If it still falls over, raise a bug with Sun.