You are right. Nothing helfull...Yoav recommendations are probably the way to explore now....You should file a bug and try to escalate it on the SUN web site.

-- Jeanfrancois

Aymeric Alibert wrote:

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]>



Reply via email to