Cu is getting a Core dump and the complete details are as below.

 SysConfig: Solaris OS version used (output of 'uname -a') SunOS tfsitdu1 5.6 Generic_105181-29 sun4u sparc SUNW,Ultra-Enterprise
                        HW used (any multi-CPU configuration),
         JDK version used (output of 'java -version' and 'java -fullversion')
  java -version:
   java version "1.3.1_01"
   Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
   Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
  java -fullversion:
   java full version "1.3.1_01"
        - problem description
                what is the problem ?
   java vm which is used by the servlet container (JRun3.1) starts to consume a lot of CPU time
   and eventually core dumps producing the following log file

    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : 10 occurred at PC=0xef77ff4c
    Function name=thr_sighndlrinfo
    Library=/usr/lib/libthread.so.1
 
    Current Java thread:
     at java.lang.Thread.start(Native Method)
     at dataservice.CorbaServiceServlet.ORBShutdown(CorbaServiceServlet.java:557)
     at dataservice.CorbaServiceServlet.access$3(CorbaServiceServlet.java:544)
     at dataservice.CorbaServiceServlet$Watcher.run(CorbaServiceServlet.java:131)

    Dynamic libraries:
     0x10000 /usr/j2se/bin/../bin/sparc/native_threads/java
     0xef770000 /usr/lib/libthread.so.1
     0xef7b0000 /usr/lib/libdl.so.1
     0xef680000 /usr/lib/libc.so.1
     0xef750000 /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
     0xee880000 /usr/j2se/jre/lib/sparc/client/libjvm.so
     0xef630000 /usr/lib/libCrun.so.1
     0xef610000 /usr/lib/libsocket.so.1
     0xef500000 /usr/lib/libnsl.so.1
     0xef5e0000 /usr/lib/libm.so.1
     0xef660000 /usr/lib/libw.so.1
     0xef5b0000 /usr/lib/libmp.so.2
     0xef4d0000 /usr/j2se/jre/lib/sparc/native_threads/libhpi.so
     0xef4a0000 /usr/j2se/jre/lib/sparc/libverify.so
     0xef460000 /usr/j2se/jre/lib/sparc/libjava.so
     0xef430000 /usr/j2se/jre/lib/sparc/libzip.so
     0xe3f60000 /usr/j2se/jre/lib/sparc/libnet.so
     0xe3f40000 /usr/lib/nss_files.so.1

    Local Time = Tue Oct 23 13:33:04 2001
    Elapsed Time = 7170
    #
    # The exception above was detected in native code outside the VM
    #
    # Java VM: Java HotSpot(TM) Client VM (1.3.1_01 mixed mode)
    #
                Has Problem always been present?
   yes, since we have moved our applications to java 2
                Is the problem consistently reproducible ?
   it does happen often , but there is no visible pattern which can be used to reproduce situation
                When did the problem start happening ?
   since we have moved our apps to java 2
                What changes have been made to the system recently?
   upgrade to java 2

        - exact error message
                What is the exact error message?
   see the log file text above, sometimes we will get segmentation fault on standard out but not always
                Where are the errors coming from ? Are they consistent ?
   i think from VM, they seem to be consistent
                did jvm print out threads & monitor information, before exiting ? - no
                (is this info consistent, from one jvm crash to another?)
                (need to check middleware sw log files if applicable)
 
   
        - what java APIs were being used when this application was created ?
   servlet 2.2 api, jdbc, CORBA (using IONA orb)
                Does this application has any native code (C/C++)(using JNI)?
   no
        - Does this application use/dependant on, any 3rd party sw (ex: middleware,
                etc)? If so, is the middleware sw vendor contacted on this problem?
   our servlets run inside JRun 3.1, we've talked to the vendor they did test
   it with jdk1.3.1 and certify it
                Any insights into the problem from middleware sw vendor? - no
                Does the problem happen with other versions of middleware sw? - no other versions of middleware are used
                Does the problem happen if the middleware native code sw is turned OFF? - middleware has no native code in it
                Is middleware certified for this version of the JDK? yes

        - Are any JDBC drivers (from 3rd party) being used ? If so, are these 100% pure - oracle thin jdbc driver (100% java)
                java drivers, or native drivers ? - java drivers
                Does the problem happen using 100% pure JDBC java drivers ? - yes

        - what JVM options are being used when invoking this application ?
                (need to check middleware startup files if applicable)
  -Dpointbase.ini=../../pointbase/pointbase.ini -Xmx64M -Djdbc.drivers=oracle.jdbc.driver.OracleDriver -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser -Dorg.omg.CORBA.ORBClass=IE.Iona.OrbixWeb.CORBA.ORB -Dorg.omg.CORBA.ORBSingletonClass=IE.Iona.OrbixWeb.CORBA.singletonORB -DDataContainer.parserClass=org.apache.xerces.parsers.SAXParser -DTLA.SecurityServices.AltLDAPHostName.0=tfisdbu3 -DTLA.SecurityServices.AltLDAPPort.0=389 -DTLA.SecurityServices.AltLDAPHostName.1=tfsndsu4 -DTLA.SecurityServices.AltLDAPPort.1=389
 
                (are the same jvm options being used on all the jvm crash' systems) - yes

        - does the problem happen if JIT is turned off ?
                ($java -Djava.compiler=none <classname>) - have not tried

        - does the problem/scenario tested with other versions of JDK AND/OR
                other Solaris versions ? - problem is not happenning under jdk1.1.8 on the same OS

        - Is this problem reproducible on the latest version of the JDK? - yes

        - does the problem/scenario tested exhibit itself on other servers at the site ? -yes

        - (for Solaris jdk 1.3.x) Does the problem happen with client hotspot (using
                '-client' option with jvm, as opposed to a '-server' option) ?,
                and vice versa ? - only used default (client)

        - (for jdk 1.2.x) Any jvm/jit environment variables being used
                (i.e., any environment variables like _JIT_ARGS & _JVM_ARGS being set)?
  no

        - typically we ask for a test case of less than 200 lines (could be flexible)
                with compiling instructions and steps to reproduce the problem;
          but for jvm crashes, we can take big chunks of standalone reproducible
                java application/code
                (please make sure that test case mimics the actual problem)
                (unfortunately we do not have ability to setup 3rd party middleware
                software inhouse, for various reasons)
          reproducible application helps towards faster resolution
  as i said above we cannot deterimne a pattern which leads to described symptoms