Chris,

I have implemented and tested this process (if I kill the java process, I can see that it was killed and the exit code.).

In the meantime, the system failed again. Light load this time and it was restarted at 1:00AM this morning so it should not have had any carryover from yesterday. The only thing I have done is to access application B several times to see if that would trigger a failure (application A is production.) Maybe it did and maybe it didn't. The core file showed the same information as previous failures:

This GDB was configured as "x86_64-slackware-linux".
(no debugging symbols found)
Core was generated by `/usr/local/java/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf'.
Program terminated with signal 11, Segmentation fault.

I have tried attaching gdb to a currently running Tomcat and I get seg fault after seg fault but it lets me continue. Not certain what that means but it looks more and more like I will have to build a jvm from source with debugging symbols. Does anyone know of a way to force a java stack dump when the jvm seg faults?

The good news is that I have now switched to the server I built this morning to see how it holds up (eliminated the jre from the install instead of removing it afterwards.)

Thanks,

Carl

----- Original Message ----- From: "Christopher Schultz" <ch...@christopherschultz.net>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Friday, February 12, 2010 10:49 AM
Subject: Re: Tomcat dies suddenly


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeffrey,

On 2/12/2010 10:31 AM, Jeffrey Janner wrote:
Also, the OP mentioned that it doesn't seem to occur if only the
production app is being hit.  It takes someone using one of the other
copies first to generate the problem. So the questions occur:

1) Are you absolutely positive that there is no code that could be
calling exit()?

One way to check this would be to launch the JVM using a script that
captures the exit code of the process:

$!/bin/sh

# Grab all these variable definitions from bin/catalina.sh

   "$_RUNJAVA" "$LOGGING_CONFIG" $JAVA_OPTS $CATALINA_OPTS \
     -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
     -Dcatalina.base="$CATALINA_BASE" \
     -Dcatalina.home="$CATALINA_HOME" \
     -Djava.io.tmpdir="$CATALINA_TMPDIR" \
     org.apache.catalina.startup.Bootstrap "$@" start \
     >> "$CATALINA_BASE"/logs/catalina.out 2>&1

result=$?

echo "JVM existed with status code=${result}"

If it's 0, then the changes that this is due to a System.exit(0) call
are very high.

You could also try running under a SecurityManager, and prohibit
System.exit() calls.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt1eKMACgkQ9CaO5/Lv0PBMIACgkZAP4UQQqVpELU2Ej4HQFOLI
7GEAn1rsUxRxvyXBrKGBYlomkaI0WN8C
=hSGU
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to