tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pete <p...@claudia.dyn.dhs.org>
Subject Re: Segmentation Fault when modifying classpath?!
Date Mon, 03 Sep 2001 10:36:38 GMT
Yeah using -classic works too, but you're much better off using IBM's 
JVM in that case.

I believe the root cause is the fact that Sun make some assumptions 
(perhaps true for Solaris) with regard to the minimum available stack 
size for a process, which are not necessarily true under other unices.

This is definitely a JVM bug, and the 'ulimit s 2048' fix is suggested 
somewhere on the Sun site. Finding it again would be a pain in the ass, 
but you might get results searching for 'ulimit' or something.

-Pete


>
>
>I did, however, run across a post detailing a problem similar to mine.  The
>suggested solution was to set the TOMCAT_OPTS environment variable
>to -classic.  After setting this environment variable, everything ran
>nicely.  If anyone can give me any more detail on either solution, that
>would be great.  I hate to implement a fix but not know the root cause.
>
>Pete, your explanation seems plausable.  I'd be interested in knowing if
>this is a known JVM bug or a Xerces bug?
>
>Al
>
>----- Original Message -----
>From: "pete" <pete@claudia.dyn.dhs.org>
>To: <tomcat-user@jakarta.apache.org>
>Sent: Sunday, September 02, 2001 3:25 AM
>Subject: Re: Segmentation Fault when modifying classpath?!
>
>
>>You're not by any chance using Suns JDK 1.3.1 and Linux are you?
>>
>>
>>If you are, add 'ulimit -s 2048' to tomcat.sh (or just type it in the
>>shell you launch tomcat from).
>>
>>This limits the maximum stack size, but i can't give you more detail
>>than that, all i know is it works for me.
>>
>>This problem only seems to show up with xerces, but since it works fine
>>on other JVMs, and on Sun JDK1.3.1 on Windows, i'd say Sun have a buggy
>>JVM here.
>>
>>IBM's JDK does not have this problem, so that may be another option for
>>
>you.
>
>>Hope that helps
>>
>>-Pete
>>
>>>Ok...
>>>
>>>All this surrounds modifying tomcat.sh per install instructions found in
>>>apache-soap.
>>>
>>>Per Apache-Soap's "Getting Tomcat Ready", I have changed my classpath to
>>>
>put
>
>>>xerces.jar at the beginning of my classpath as follows:
>>>....
>>>unset CLASSPATH
>>>
>>>CLASSPATH=/usr/local/java/lib/xerces.jar
>>>
>>>for i in ${TOMCAT_HOME}/lib/* ; do
>>> if [ "$CLASSPATH" != "" ]; then
>>>   CLASSPATH=${CLASSPATH}:$i
>>> else
>>>   CLASSPATH=$i
>>> fi
>>>done
>>>...
>>>
>>>When starting tomcat I get the following:
>>>
>>>Using classpath:
>>>/usr/local/java/lib/xerces.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/activation.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/ant.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/jasper.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/LICENSE:
>>>/opt/jakarta-tomcat-3.2.3/lib/mail.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/servlet.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/soap.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/test:
>>>/opt/jakarta-tomcat-3.2.3/lib/webserver.jar:
>>>/opt/jakarta-tomcat-3.2.3/lib/xerces.jar:
>>>/usr/local/java/jdk1.3.1/lib/tools.jar
>>>
>>>/opt/jakarta-tomcat-3.2.3/bin/tomcat.sh: line 181: 12681 Segmentation
>>>
>fault
>
>>>$JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}
>>>org.apache.tomcat.startup.Tomcat "$@"
>>>
>>>I can not figure out for the life of me why this is happening.  I've also
>>>tried setting the classpath from the shell with the exact same results.
>>>
>Any
>
>>>hints appreciated.
>>>
>>>Thanks,
>>>
>>>Al Calbazana
>>>
>>
>>
>>




Mime
View raw message