I changed the debug flag to 10 in all elements of my server.xml.
Looking at the log file, I cannot identifiy any error or warning from
Tomcat before it crashes.
Here is a sample:
...
StandardContext[/residential]: Mapped to servlet 'default' with servlet path
'/images/home_hdr.jpg' and path info 'null' and update=true
StandardEngine[Standalone]: Mapping server name 'trngyouraccount.alliant-energy.com'
StandardEngine[Standalone]: Trying a direct match
StandardEngine[Standalone]: Trying an alias match
StandardHost[localhost]: Mapping request URI '/residential/images/dropshadow.gif'
StandardHost[localhost]: Trying the longest context path prefix
StandardHost[localhost]: Mapped to context '/residential'
Authenticator[/residential]: Security checking request GET
/residential/images/dropshadow.gif
Authenticator[/residential]: Checking constraint 'SecurityConstraint[youraccount
assistance LDAP authentication]' against GET /images/dropshadow.gif --> false
Authenticator[/residential]: No applicable constraint located
Authenticator[/residential]: Not subject to any constraint
StandardContext[/residential]: Mapping contextPath='/residential' with
requestURI='/residential/images/dropshadow.gif' and
relativeURI='/images/dropshadow.gif'
StandardContext[/residential]: Trying exact match
StandardContext[/residential]: Trying prefix match
StandardContext[/residential]: Trying extension match
StandardContext[/residential]: Trying default match
StandardContext[/residential]: Mapped to servlet 'default' with servlet path
'/images/dropshadow.gif' and path info 'null' and update=true
StandardEngine[Standalone]: Mapping server name 'trngyouraccount.alliant-energy.com'
StandardEngine[Standalone]: Trying a direct match
StandardEngine[Standalone]: Trying an alias match
StandardHost[localhost]: Mapping request URI '/residential/images/homepa2.gif'
StandardHost[localhost]: Trying the longest context path prefix
StandardHost[localhost]: Mapped to context '/residential'
Authenticator[/residential]: Security checking request GET
/residential/images/homepa2.gif
Authenticator[/residential]: Checking constraint 'SecurityConstraint[youraccount
assistance LDAP authentication]' against GET /images/homepa2.gif --> false
Authenticator[/residential]: No applicable constraint located
Authenticator[/residential]: Not subject to any constraint
StandardContext[/residential]: Mapping contextPath='/residential' with
requestURI='/residential/images/homepa2.gif' and relativeURI='/images/homepa2.gif'
StandardContext[/residential]: Trying exact match
StandardContext[/residential]: Trying prefix match
StandardContext[/residential]: Trying extension match
StandardContext[/residential]: Trying default match
StandardContext[/residential]: Mapped to servlet 'default' with servlet path
'/images/homepa2.gif' and path info 'null' and update=true
StandardEngine[Standalone]: Mapping server name 'trngyouraccount.alliant-energy.com'
StandardEngine[Standalone]: Trying a direct match
StandardEngine[Standalone]: Trying an alias match
StandardHost[localhost]: Mapping request URI '/residential/images/_c60b27.gif'
StandardHost[localhost]: Trying the longest context path prefix
StandardHost[localhost]: Mapped to context '/residential'
Authenticator[/residential]: Security checking request GET
/residential/images/_c60b27.gif
Authenticator[/residential]: Checking constraint 'SecurityConstraint[youraccount
assistance LDAP authentication]' against GET /images/_c60b27.gif --> false
Authenticator[/residential]: No applicable constraint located
Authenticator[/residential]: Not subject to any constraint
StandardContext[/residential]: Mapping contextPath='/residential' with
requestURI='/residential/images/_c60b27.gif' and relativeURI='/images/_c60b27.gif'
StandardContext[/residential]: Trying exact match
StandardContext[/residential]: Trying prefix match
StandardContext[/residential]: Trying extension match
Unexpected Signal : 11 occurred at PC=0xFFFFFFFF3981797C
Function=[Unknown.]
Library=(N/A)
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.
Current Java thread:
Dynamic libraries:
0x100000000 /SunQA/youraccount/j2sdk1.4.1_01/bin/sparcv9/java
0xffffffff7f200000 /usr/lib/64/libthread.so.1
0xffffffff7f400000 /usr/lib/64/libdl.so.1
0xffffffff7ef00000 /usr/lib/64/libc.so.1
0xffffffff7ed00000 /usr/platform/SUNW,Ultra-4/lib/sparcv9/libc_psr.so.1
0xffffffff7d000000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/server/libjvm.so
0xffffffff7d800000 /usr/lib/64/libCrun.so.1
0xffffffff7cd00000 /usr/lib/64/libsocket.so.1
0xffffffff7cb00000 /usr/lib/64/libnsl.so.1
0xffffffff7c900000 /usr/lib/64/libm.so.1
0xffffffff7da00000 /usr/lib/64/libw.so.1
0xffffffff7c600000 /usr/lib/64/libmp.so.2
0xffffffff7c300000
/SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/native_threads/libhpi.so
0xffffffff7c000000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libverify.so
0xffffffff7be00000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libjava.so
0xffffffff7bb00000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libzip.so
0xffffffff13a00000 /usr/lib/locale/en_US.ISO8859-1/sparcv9/en_US.ISO8859-1.so.2
0xffffffff10a00000 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libnet.so
Local Time = Tue Oct 31 11:58:52 2000
Elapsed Time = 317
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002E6 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.1_01-b01 mixed mode)
#
# An error report file has been saved as hs_err_pid1694.log.
# Please refer to the file for further information.
#
>>> [EMAIL PROTECTED] 12/10/02 06:53PM >>>
Have you try running your test and verbosing as much as possible
information inside the log file (increase the debug level in
server.xml)? Try it to see if Tomcat 4.1.x output something useful to
trace the problem. Post your result (ot the last couple of lines). Maybe
it will help.
-- Jeanfrancois
Aymeric Alibert wrote:
> Thanks for the feedback.
>
> When I ran my load tests I used -Xmx512m -Xms512m as heap settings.
> I also tried increasing or decreasing it but it didn't change the results.
> I am running on Solaris and I have all the recommended patches for
> JDK1.4.1 installed.
>
> I can reproduce the problem: it is always crashing during the test,
> but it can be after 2 minutes or 20 minutes depending on the run.
> My problem is that I cannot create a simple test case that will crash the
> server because of the complexity of our environment ( it includes
> multiples
> Oracle databases and LDAP connectivity).
> I tried to isolate the problem to a single jsp like you recommend
> it but that didn't work.
> (I could fine several combinations that would trigger the crash).
> So I am not sure what I could provide as a test case except our full
> dev environment.
>
> I can deploy the same application on TC4.0.4 and it runs fine. I tried
> many versions
> of Tomcat 4.1 (4.1.7, 4.1.12, 4.1.14 and 4.1.16) and are all failing.
>
> I attached the VM log.
>
> Thanks,
>
>
> Aymeric
>
>
>
> >>> [EMAIL PROTECTED] 12/10/02 04:48PM >>>
> Howdy,
> If your OS requires patches in order to run the JDK (whatever version
> you're trying to run), make sure those patches are installed. I had
> this exact issue happen on Solaris, and installing the proper Solaris
> patches made it go away.
>
> You say "The same behavior can be reproduced with both JDK1.4.0 and
> JDK1.4.1" and yet "I cannot create a test case to reproduce my problem."
> Which one is it? ;) If you can reproduce it, the full details of how
> to reproduce it can be posted to Sun's bug parade, and they'll track
> down whatever tools they need in order to mimic your environment. If
> you can't reproduce it, there's no bug as far as they're concerned.
>
> Finally, I'm not sure I understand this bullet:
>
> >- I works fine with TC4.1
>
> So your app works fine on TC 4.1? I thought that was the whole problem?
> Or did you mean it works fine with TC 4.0 and not 4.1? If it's the
> latter, as I suspect, perhaps you could start by deploying a very small
> subset of your app and repeating the test. Then increase the deployed
> subset and retest. The idea is that a certain feature of tomcat as used
> by your app is crashing the VM, and to find out which section of your
> app is causing this. The more you can narrow it down, the better.
>
> Yoav Shapira
> Millennium ChemInformatics
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
