You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Mike Cherichetti (Renegade Internet)" <mi...@renegadeinternet.com> on 2004/10/07 22:14:57 UTC
Weird Red Hat Enterprise Startup
Hi,
I'm getting this strange error in catalina.out on Red Hat Enterprise Linux
AS and CentOS:
****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC = 0x00000000
SIGNAL = 11
FUNCTION NAME = (N/A)
OFFSET = 0xFFFFFFFF
LIBRARY NAME = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
****************
When this happens, Tomcat just fails to start. However, if I try to start
Tomcat again it will work. Sometimes it takes 2 or 3 retries. As this
error message doesn't really provide any help at all in figuring this out,
I'm wondering if anyone has any tips to try and figure out what's happening?
I don't think this is a problem with Tomcat, but I think it may be something
in the startup.sh/catalina.sh/shutdown.sh scripts. Oh yeah, sometimes this
happens with the shutdown call too.
Also, I've tried this with Sun JDK 1.4.1/1.4.2, Apache 1.3/2.0,
mod_jk/mod_jk2, and Tomcat 4.1/5.0. No problems with Red Hat 7, 8, or 9.
Have a nice day ...
Sincerely,
Mike Cherichetti
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: Weird Red Hat Enterprise Startup
Posted by "Mike Cherichetti (Renegade Internet)" <mi...@renegadeinternet.com>.
Thanks for the info. I just want to make sure, are you saying that I should
put "-server" in JAVA_OPTS and CATALINA_OPTS? Because I already have it set
in CATALINA_OPTS right now. I think maybe I'll only need it in JAVA_OPTS,
because if I recall those get passed to Tomcat too along with CATALINA_OPTS.
Have a nice day ...
Sincerely,
Mike Cherichetti
-----Original Message-----
From: news [mailto:news@sea.gmane.org]On Behalf Of Shankar Unni
Sent: Thursday, October 07, 2004 4:24 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: Weird Red Hat Enterprise Startup
Mike Cherichetti (Renegade Internet) wrote:
> Another exception has been detected while we were handling last error.
> Dumping information about last error:
> ERROR REPORT FILE = (N/A)
> PC = 0x00000000
This is the Java VM aborting. You'll probably find core.* files littered
in the Tomcat directory from java.
I've been running into this same problem with Java 1.4.2_0x (including
_05) on Red Hat EL 3.0.
One (not guaranteed or foolproof) workaround is to run java with the
"-server" option (you'll have to pass it in via the JAVA_OPTS env
variable or something). This made the crash go away in our setup. You
can also play with the heap params and see if that helps. The crash is
in some GC processing that kicks in at the wrong moment..
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Weird Red Hat Enterprise Startup
Posted by Shankar Unni <sh...@netscape.net>.
Mike Cherichetti (Renegade Internet) wrote:
> Another exception has been detected while we were handling last error.
> Dumping information about last error:
> ERROR REPORT FILE = (N/A)
> PC = 0x00000000
This is the Java VM aborting. You'll probably find core.* files littered
in the Tomcat directory from java.
I've been running into this same problem with Java 1.4.2_0x (including
_05) on Red Hat EL 3.0.
One (not guaranteed or foolproof) workaround is to run java with the
"-server" option (you'll have to pass it in via the JAVA_OPTS env
variable or something). This made the crash go away in our setup. You
can also play with the heap params and see if that helps. The crash is
in some GC processing that kicks in at the wrong moment..
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org