Unparameterized THROW results in core dump.

Hi,
There is a strange problem which I am not able to comprehend at all. When I use an unparameterized throw in my c++ program it dumps but a parameterized throw works fine without any problems. I searched on the internet for any reasoning but unfortunately couldnt find anything related to my problem.
Below is the program I am using.
#include <iostream>
#include<string>
using namespace std;
void foo(int i)
        try
                         if (i==0)
                        cout<<"THROWING DEFAULT EXCEPTION FROM FOO \n";
                        throw ;
        catch (...)
                cout<<"IN DEFAULT CATCH OF FOO \n";
                throw;
        try
                if (i == 1)
                        cout<<"THROWING PARAMATERIZED EXCEPTION FROM FOO \n";
                        throw 1;
        catch (...)
                cout<<"IN PARAMATERIZED CATCH OF FOO \n";
                throw 1;
int main()
        int i;
        cout<<"start main\n";
        cout<<"Enter a number: 0 - FOR DEFAULT THROW, 1 - PARAMATERIZED THROW \n";
        cin>>i;
        try
                foo(i);
        catch (...)
                cout<<"IN catch of main \n";
        cout<<"End Main \n";
}Compilation option:
CC -g -o throw.exe throw.cc
I would be really appreciate if anyone can let me know the reasoning behind this behavior.
regards,
Ankur.

Copies of the C++ standard are available from INCITS (www.incits.org), the body that charters the US C++ Committee, at their store:
[http://www.techstreet.com/cgi-bin/detail?product_id=1143945]
A downloadable PDF file costs US $30.
If you want a hard copy, the best choice is the hardcover book published by John Wiley (www.wiley.com) for US $85. The book is bound so that it lies flat when opened to any page. It is printed from the same electronic files that produced the official standard, so it is an exact copy.
from the publisher: [http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470846747.html]
from amazon.com: [http://www.amazon.com/C%2B%2B-Standard-Incorporating-Technical-Corrigendum/dp/0470846747/sr=11-1/qid=1164141690/ref=sr_11_1/103-7967641-2022251]

Similar Messages

  • Spatial query results in core dump

    Following query leads to a core dump error. I only can get the first 45 rows.
    ksedmp: internal or fatal error
    ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [_kokekd2m+43] [PC:0x13A71A3] [ADDR:0x65CECD14] [UNABLE_TO_READ] []
    SELECT geom.link_id, geom.link
    FROM state
    JOIN link ON state.state_id=link.state_id
    JOIN geom ON link.link_id=geom.link_id
    WHERE MDSYS.SDO_FILTER(link, MDSYS.SDO_GEOMETRY(2003, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY(-118, 36, -114, 40)), 'querytype=WINDOW') = 'TRUE'
    AND state.class=1
    If i change the select clause to:
    SELECT count(geom.link_id) ...
    it works fine.
    Does anyone has similar experience?

    Hi,
    I'm not sure this is exactly relevant but there used to be a bug (certainly in 9i) wherby if you had a SDO_GEOMETRY column in a result set (or subquery) that was being subjected to a sort operation and there were more than a certain figure (32K rings a bell although I could be wrong on that) of rows then it would die. The sort wasn't necessarily a "user" sort - it could be being performed by the database to speed up a join or group by.
    Which version of the DB are you using?
    If you just try this :
    SELECT geom.link_id
    FROM state
    JOIN link ON state.state_id=link.state_id
    JOIN geom ON link.link_id=geom.link_id
    WHERE MDSYS.SDO_FILTER(link, MDSYS.SDO_GEOMETRY(2003, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY(-118, 36, -114, 40)), 'querytype=WINDOW') = 'TRUE'
    AND state.class=1
    i.e just remove the geometry column from the results set, does this work?
    If it does than you may need to wrap this (working) query up as a subselect and join back to your original table to get the geometry "back" if you need it.....
    Steve

  • Increasing the number of thread results in core dump

    Hi all ,
    I am having application in C++ on Solaris and WIn NT OS . In Win Nt if the Number of Threads Spawned is 50 it's working fine but if we try the same it results in Core , but if we reduce the number of Threads spawned to 40 the application works just fine . The System configuration for WIn NT is 512 RAM and for Solaris is 1GB . Any pointers to what can be the possible reason and solution to the cause .
    Regards
    Rahul

    Hi,
    The basis sets the maximum number of pages that can be printed by the user in authorization object S_SPO_PAGE.
    Please discuss with your basis guy.
    Tyken

  • OCI Call resulting in core dump

    Hi,
    I have a C++ code that is resulting in segmentation fault when for a particular query define_by_position( ) (this calles OCI odefin()) is called. this function is running in loop and for other queries it successfully completes but for one particular query it always result in seg fault. Code was compiled for Solaris using following compiler with -m64 flag.
    [nus825:sr54713] /opt/sfw/bin >> g++ -v
    Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.2/specs
    Configured with: ../configure with-as=/usr/ccs/bin/as with-ld=/usr/ccs/bin/ld --disable-nls
    Thread model: posix
    gcc version 3.4.2
    Here is the code.
    bool OracleConduit::doSelect(string inputQuery)
            if(m_cur_numfields!=0)
                    for (int a=0; a<m_cur_numfields;a++){
                            delete m_cur_info[a].col_data;
            //m_SQL_SelFilesToDelete, colsinfo_3, 1
            //doSelect(m_SQL_SelMaxCon,colsinfo_4,1
            //doSelect(m_SQL_SelFileToProcess,colsinfo_2,5
            if(inputQuery==m_SQL_SelFilesToDelete)
                FullReplace(inputQuery,"DISP_END_TS","TO_CHAR(DISP_END_TS, 'YYYY-MM-DD HH24:MI:SS')");
                m_cur_info = colsinfo_3;
                m_cur_numfields =1;
            else if(inputQuery==m_SQL_SelMaxCon || inputQuery==m_SQL_SelMinCon )
                    m_cur_info  = colsinfo_4;
                    m_cur_numfields = 1;
            else if(inputQuery==m_SQL_SelFileToProcess)
                    m_cur_info  = colsinfo_2;
                    m_cur_numfields = 4;
            else if(inputQuery==m_SQL_SelFromCon)
                    m_cur_info  = colsinfo;
                    m_cur_numfields = 17;
        int a;
            oCur.close();
        if (oCur.open(&oConn))
          return false;
    cout << inputQuery.c_str() << endl ;
        if (oCur.parse((const unsigned char *)inputQuery.c_str()))
          return false;
        /* describe the select-list field "Event_TS" */
            for (a=0; a<m_cur_numfields;a++){
                            m_cur_info[a].col_name_len = sizeof (m_cur_info[a].col_name_buf);
                            if (oCur.describe(a+1,
                                            &(m_cur_info[a].col_data_len),
                                            &(m_cur_info[a].db_type),
                        m_cur_info[a].col_name_buf,
                                            &(m_cur_info[a].col_name_len),
                        &(m_cur_info[a].dsize),
                                            (sb2 *) 0,
                        (sb2 *) 0,
                                            (sb2 *) 0)
                              oCur.display_error(stderr);
                              return false;
                            /* allocate space for dept name now that you have length */
                            sword allocLen = m_cur_info[a].col_data_len + 1;
                            m_cur_info[a].col_data = new text[allocLen];
                            /* define the output variable for the select-list */
                            //ub2 rlen, rcode;
                            //text *datptr = m_cur_info[a].col_data;
                            //ub1 *cdatptr= (ub1 *)datptr;
                            cout << "oCur.define_by_position" << endl;
                            if (oCur.define_by_position(a+1,
                                            m_cur_info[a].col_data,
                                            allocLen,
                                            STRING_TYPE,
                                            -1,
                                            &m_cur_info[a].indic,
                                            &m_cur_info[a].rlen,
                                            &m_cur_info[a].rcode)
                              oCur.display_error(stderr);
                              for (a=0; a<m_cur_numfields;a++){
                                    delete m_cur_info[a].col_data;
                              return false;
                            cout << "oCur.define_by_position successed" << endl;
        if (oCur.execute())
          if (oCur.get_error_code() != NO_DATA_FOUND)
            oCur.display_error(stderr);
                for (a=0; a<m_cur_numfields;a++){
                            delete m_cur_info[a].col_data;
            return false;
         else
            return true;
        else
                    return true;
    }

    You problem sounds like an Oracle issue, not necessarily a Sun C++ compiler issue. I suggest you take up this question first with Oracle.

  • OCCI Threading - core dumps

    Hi,
    After learning howto setup my OCCI Environment handle
    correctly for threads using;
    Environment::Mode mode = (Environment::THREADED_MUTEXED,
    Environment::OBJECT);
    The class that encapsulates this is a singleton and used
    through out the process by all the threads. This class
    conection pools and is synchronised for all the threads.
    However, using this singleton model, I get core dumps
    when more than 1 thread attempts to execute a commit on
    the database via the connection they have obtained from
    this singleton class.
    Instantiating the class or environment per thread does
    not result in core dumps. Rather it runs smoothly.
    Is this normal behaviour?
    (Also when all the threads are querying the singleton
    model works fine. Seems only commits)
    Raffaele

    Hi,
    I tried the THREADED_MUTEX|OBJECT but I still get core
    dumps when threading. What I experience is during a
    connection->commit() or any other call on a connection
    when threading causes a core dump.
    I use the OCCI object inrterface and my db is an object
    schema. I am trying to use the full OO dev that comes
    with Oracle...ott included.
    Everything boils down to my singleton DB class which
    is shown below; (Is there any other thread initialisation
    required)
    #include <db/oracle.h>
    #include <env/config.h>
    #include <env/errlog.h>
    #include <env/stdenv.h>
    #include <taucpp/except_base.h>
    #include <gtcpp/mtlock.h>
    #include <gtcpp/debug.h>
    GTFILE;
    static GtMtCritSec db_mutex;
    Oracle::Oracle (GtString &userName,
    GtString &password,
    GtString &url,
    int max,
    int min,
    int inc) :
    _user (userName),
    _pwd (password),
    _url (url),
    _max (max),
    _min (min),
    _inc (inc),
    _connection (0)
    GtMtAutoLock lock (db_mutex);
    Environment::Mode mode
    = (Environment::Mode) (Environment::THREADED_MUTEXED | Environment::OBJECT);
    _system = Environment::createEnvironment (mode);
    char* s = getenv ("ORACLE_HOME");
    if (!s || (strlen (s) == 0))
    cout << "environment variable ORACLE_HOME not initialized"
    << endl;
    connect ();
    Oracle::~Oracle ()
    GtMtAutoLock lock (db_mutex);
    if (_connection)
    system->terminateConnectionPool (connection);
    Environment::terminateEnvironment (_system);
    void Oracle::getConnection (Connection** connection)
    GTASSERT (connection);
    GtMtAutoLock lock (db_mutex);
    try
    if (_connection)
    *connection = connection->createConnection ( (char*)& (*user),
    (char*)& (*_pwd));
    else
    Exception ex ("MSN reconnect exception");
    *connection = 0;
    throw ex;
    catch (SQLException ex)
    retry ();
    catch(Exception ex)
    retry();
    catch (...)
    void Oracle::retry ()
    GtMtAutoLock lock (db_mutex);
    try
    if (_connection)
    system->terminateConnectionPool (connection);
    catch (...)
    connect ();
    void Oracle::terminateConnection (Connection* connection)
    GTASSERT (connection);
    GtMtAutoLock lock (db_mutex);
    if (connection)
    try
    if (_connection)
    _connection->terminateConnection (connection);
    catch (SQLException ex)
    catch (...)
    Environment* Oracle::getEnvironment ()
    GtMtAutoLock lock (db_mutex);
    return _system;
    void Oracle::connect ()
    GtMtAutoLock lock (db_mutex);
    try
    connection = system->createConnectionPool ( (char*)& (*_user),
    (char*)& (*_pwd),
    (char*)& (*_url),
    min,max,_inc);
    catch (SQLException ex)
    _connection = 0;
    catch (...)
    _connection = 0;
    Any help much appreciated,
    Raffaele

  • Throws Core Dump for OCISessionBegin() on Linux for Oracle Client v10.2.0.2

    hi,
    The OCI method, OCISessionBegin() is throwing an core dump on 10g client in Linux on C++, but the same code works fine for 8i and 9i client. Core dumps for 10g Client. 10g tnsnames.ora file is same as of 9i. I just debeggued with the core and says failing in OCISessionBegin() method. I would like to know is there any problem with Oracle Client v10.2.0.2? or how does i can solve the issue? appriciate a quick help in this regard.
    Thanks,
    Sreeni

    Have you looked in the Knowledge Base information at metalink? That would be the place to start.
    If that does not work then the next step would be to remove this thread and post in the OCI - OCCI forum where there are people that can actually help you.

  • JDB crashes while lodading core dump or throws errors

    I'm having here RHEL 5.1 system and some core dumps generated by our 32 bit java application. This application uses JNI and for some reason (that I'm still trying to figure out) is crashing while executing JNI calls.
    I can load the core dumps inside gdb and even backtrace the native stack of the program and see the variables inside the shared library where it's crashing. But I need to take a closer look on the java stack and some of the variable values on the java side also.
    I did try to use JDB to do this like it's described in the Troubleshooting guide for Java 6 but for some unknown reason when I do try to attach JDB to the core dumps I either get some error thrown on the console or JDB crashes and produces a hs_err_pit*.log file. I have used this technique already few times and didn't had any problems with JDB. I'm wondering if it could be that the core dump files are too big - some of them are around 3 Gb. But one of them is ~600Mb and also is crashing. So is ti possible bug in JDB or I'm missing something. I'm posting the error and the one of the hs_err_pid files.
    Appreciate any help and ideas
    $ jdb -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=/usr/java/jdk/bin/java,core=core.31919
    java.io.IOException
    at sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(SACoreAttachingConnector.java:123)
    at com.sun.tools.example.debug.tty.VMConnection.attachTarget(VMConnection.java:358)
    at com.sun.tools.example.debug.tty.VMConnection.open(VMConnection.java:168)
    at com.sun.tools.example.debug.tty.Env.init(Env.java:64)
    at com.sun.tools.example.debug.tty.TTY.main(TTY.java:1010)
    Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at sun.jvm.hotspot.jdi.SACoreAttachingConnector.createVirtualMachine(SACoreAttachingConnector.java:80)
    at sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(SACoreAttachingConnector.java:108)
    ... 4 more
    Caused by: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:258)
    at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:625)
    at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:611)
    at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:322)
    at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:297)
    at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:157)
    at sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForCorefile(VirtualMachineImpl.java:190)
    ... 10 more
    Fatal error:
    Unable to attach to target VM.
    # An unexpected error has been detected by Java Runtime Environment:
    # SIGSEGV (0xb) at pc=0xafcfa6bd, pid=3653, tid=4160613264
    # Java VM: Java HotSpot(TM) Server VM (1.6.0_03-b05 mixed mode)
    # Problematic frame:
    # C [libsaproc.so+0x36bd]
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    --------------- T H R E A D ---------------
    Current thread (0x08058000): JavaThread "main" [_thread_in_native, id=3654]
    siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000151
    Registers:
    EAX=0xf7ffdabc, EBX=0xafcff25c, ECX=0xafd72d08, EDX=0x00000149
    ESP=0xf7fdc520, EBP=0xf7fdc538, ESI=0xafd72d08, EDI=0x08058000
    EIP=0xafcfa6bd, CR2=0x00000151, EFLAGS=0x00010206
    Top of Stack: (sp=0xf7fdc520)
    0xf7fdc520: 464c457f 00010101 000000a2 0000009c
    0xf7fdc530: 0000009f afcff25c f7fdc588 afcfb01a
    0xf7fdc540: afd67780 f7ffdabc 00200034 afcfaff4
    0xf7fdc550: 004a004b 00000000 00200034 0028000a
    0xf7fdc560: 004a004b afba13e0 00001110 afcff25c
    0xf7fdc570: afb8e2e8 08058000 f7fdc5a8 afcf93b3
    0xf7fdc580: 00000004 afcff25c f7fdc5a8 afcf9964
    0xf7fdc590: afd67780 f7ffdabc f7fdd72c 00000004
    Instructions: (pc=0xafcfa6bd)
    0xafcfa6ad: 8d 14 85 00 00 00 00 8b 41 24 8b 14 10 8b 45 0c
    0xafcfa6bd: 3b 42 08 72 08 8b 45 f8 89 45 f4 eb b1 8b 45 f8
    Stack: [0xf7f8e000,0xf7fdf000), sp=0xf7fdc520, free space=313k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    C [libsaproc.so+0x36bd]
    C [libsaproc.so+0x401a]
    C [libsaproc.so+0x2964] ps_pdread+0x1c
    C [libsaproc.so+0x4d3e]
    C [libsaproc.so+0x4ffd] Pgrab_core+0x281
    C [libsaproc.so+0x56c7] Java_sun_jvm_hotspot_debugger_linux_LinuxDebuggerLocal_attach0__Ljava_lang_String_2Ljava_lang_String_2+0x99
    j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Ljava/lang/String;Ljava/lang/String;)V+0
    j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(Ljava/lang/String;Ljava/lang/String;)V+29
    j sun.jvm.hotspot.HotSpotAgent.attachDebugger()V+43
    j sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux()V+122
    j sun.jvm.hotspot.HotSpotAgent.setupDebugger()V+95
    j sun.jvm.hotspot.HotSpotAgent.go()V+1
    j sun.jvm.hotspot.HotSpotAgent.attach(Ljava/lang/String;Ljava/lang/String;)V+56
    j sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForCorefile(Lcom/sun/jdi/VirtualMachineManager;Ljava/lang/String;Ljava/lang/String;I)Lsun/jvm/hotspot/jdi/VirtualMachineImpl;+58
    v ~StubRoutines::call_stub
    V [libjvm.so+0x2c5ecd]
    V [libjvm.so+0x4523b8]
    V [libjvm.so+0x2c5d60]
    V [libjvm.so+0x49a08f]
    V [libjvm.so+0x49ca8c]
    V [libjvm.so+0x331e88]
    C [libjava.so+0x15224] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x34
    j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
    j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
    j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
    j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
    j sun.jvm.hotspot.jdi.SACoreAttachingConnector.createVirtualMachine(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;)Lcom/sun/jdi/VirtualMachine;+122
    j sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(Ljava/util/Map;)Lcom/sun/jdi/VirtualMachine;+90
    j com.sun.tools.example.debug.tty.VMConnection.attachTarget()Lcom/sun/jdi/VirtualMachine;+13
    j com.sun.tools.example.debug.tty.VMConnection.open()Lcom/sun/jdi/VirtualMachine;+33
    j com.sun.tools.example.debug.tty.Env.init(Ljava/lang/String;ZI)V+28
    j com.sun.tools.example.debug.tty.TTY.main([Ljava/lang/String;)V+1207
    v ~StubRoutines::call_stub
    V [libjvm.so+0x2c5ecd]
    V [libjvm.so+0x4523b8]
    V [libjvm.so+0x2c5d60]
    V [libjvm.so+0x2ef186]
    V [libjvm.so+0x2e082b]
    C [jdb+0x1af8] JavaMain+0x2c8
    C [libpthread.so.0+0x543b]
    Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
    j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Ljava/lang/String;Ljava/lang/String;)V+0
    j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(Ljava/lang/String;Ljava/lang/String;)V+29
    j sun.jvm.hotspot.HotSpotAgent.attachDebugger()V+43
    j sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux()V+122
    j sun.jvm.hotspot.HotSpotAgent.setupDebugger()V+95
    j sun.jvm.hotspot.HotSpotAgent.go()V+1
    j sun.jvm.hotspot.HotSpotAgent.attach(Ljava/lang/String;Ljava/lang/String;)V+56
    j sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForCorefile(Lcom/sun/jdi/VirtualMachineManager;Ljava/lang/String;Ljava/lang/String;I)Lsun/jvm/hotspot/jdi/VirtualMachineImpl;+58
    v ~StubRoutines::call_stub
    j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
    j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
    j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
    j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
    j sun.jvm.hotspot.jdi.SACoreAttachingConnector.createVirtualMachine(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;)Lcom/sun/jdi/VirtualMachine;+122
    j sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(Ljava/util/Map;)Lcom/sun/jdi/VirtualMachine;+90
    j com.sun.tools.example.debug.tty.VMConnection.attachTarget()Lcom/sun/jdi/VirtualMachine;+13
    j com.sun.tools.example.debug.tty.VMConnection.open()Lcom/sun/jdi/VirtualMachine;+33
    j com.sun.tools.example.debug.tty.Env.init(Ljava/lang/String;ZI)V+28
    j com.sun.tools.example.debug.tty.TTY.main([Ljava/lang/String;)V+1207
    v ~StubRoutines::call_stub
    --------------- P R O C E S S ---------------
    Java Threads: ( => current thread )
    0xafd08c00 JavaThread "Thread-1" daemon [_thread_blocked, id=3682]
    0x0819b000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3680]
    0x08199400 JavaThread "CompilerThread1" daemon [_thread_blocked, id=3679]
    0x08198000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3678]
    0x08196c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3677]
    0x08183c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3676]
    0x08183400 JavaThread "Reference Handler" daemon [_thread_blocked, id=3675]
    =>0x08058000 JavaThread "main" [_thread_in_native, id=3654]
    Other Threads:
    0x08180800 VMThread [id=3671]
    0x0819c800 WatcherThread [id=3681]
    VM state:not at safepoint (normal execution)
    VM Mutex/Monitor currently owned by a thread: None
    Heap
    PSYoungGen total 9280K, used 2718K [0xedca0000, 0xee6f0000, 0xf4e60000)
    eden space 8000K, 33% used [0xedca0000,0xedf47b40,0xee470000)
    from space 1280K, 0% used [0xee5b0000,0xee5b0000,0xee6f0000)
    to space 1280K, 0% used [0xee470000,0xee470000,0xee5b0000)
    PSOldGen total 84992K, used 0K [0xb4e60000, 0xba160000, 0xedca0000)
    object space 84992K, 0% used [0xb4e60000,0xb4e60000,0xba160000)
    PSPermGen total 16384K, used 3088K [0xb0e60000, 0xb1e60000, 0xb4e60000)
    object space 16384K, 18% used [0xb0e60000,0xb1164398,0xb1e60000)
    Dynamic libraries:
    00b31000-00b4a000 r-xp 00000000 fd:00 5932045 /lib/ld-2.5.so
    00b4a000-00b4b000 r-xp 00019000 fd:00 5932045 /lib/ld-2.5.so
    00b4b000-00b4c000 rwxp 0001a000 fd:00 5932045 /lib/ld-2.5.so
    00b4e000-00c88000 r-xp 00000000 fd:00 5932057 /lib/libc-2.5.so
    00c88000-00c8a000 r-xp 00139000 fd:00 5932057 /lib/libc-2.5.so
    00c8a000-00c8b000 rwxp 0013b000 fd:00 5932057 /lib/libc-2.5.so
    00c8b000-00c8e000 rwxp 00c8b000 00:00 0
    00c90000-00ca3000 r-xp 00000000 fd:00 5932059 /lib/libpthread-2.5.so
    00ca3000-00ca4000 r-xp 00012000 fd:00 5932059 /lib/libpthread-2.5.so
    00ca4000-00ca5000 rwxp 00013000 fd:00 5932059 /lib/libpthread-2.5.so
    00ca5000-00ca7000 rwxp 00ca5000 00:00 0
    00ca9000-00cab000 r-xp 00000000 fd:00 5932058 /lib/libdl-2.5.so
    00cab000-00cac000 r-xp 00001000 fd:00 5932058 /lib/libdl-2.5.so
    00cac000-00cad000 rwxp 00002000 fd:00 5932058 /lib/libdl-2.5.so
    00caf000-00cb6000 r-xp 00000000 fd:00 5932062 /lib/librt-2.5.so
    00cb6000-00cb7000 r-xp 00006000 fd:00 5932062 /lib/librt-2.5.so
    00cb7000-00cb8000 rwxp 00007000 fd:00 5932062 /lib/librt-2.5.so
    00d9b000-00dc0000 r-xp 00000000 fd:00 5932060 /lib/libm-2.5.so
    00dc0000-00dc1000 r-xp 00024000 fd:00 5932060 /lib/libm-2.5.so
    00dc1000-00dc2000 rwxp 00025000 fd:00 5932060 /lib/libm-2.5.so
    06000000-065a0000 r-xp 00000000 fd:00 16777229 /usr/java/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
    065a0000-065db000 rwxp 005a0000 fd:00 16777229 /usr/java/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
    065db000-069fc000 rwxp 065db000 00:00 0
    08048000-08052000 r-xp 00000000 fd:00 16810695 /usr/java/jdk1.6.0_03/bin/jdb
    08052000-08053000 rwxp 00009000 fd:00 16810695 /usr/java/jdk1.6.0_03/bin/jdb
    08053000-08289000 rwxp 08053000 00:00 0 [heap]
    afa00000-afa39000 rwxp afa00000 00:00 0
    afa39000-afb00000 ---p afa39000 00:00 0
    afb00000-afbf2000 rwxp afb00000 00:00 0
    afbf2000-afc00000 ---p afbf2000 00:00 0
    afcf7000-afcff000 r-xp 00000000 fd:00 16777232 /usr/java/jdk1.6.0_03/jre/lib/i386/libsaproc.so
    afcff000-afd00000 rwxp 00007000 fd:00 16777232 /usr/java/jdk1.6.0_03/jre/lib/i386/libsaproc.so
    afd00000-afe00000 rwxp afd00000 00:00 0
    afe60000-afe63000 ---p afe60000 00:00 0
    afe63000-afeb1000 rwxp afe63000 00:00 0
    afeb1000-afeb6000 r-xp 00000000 fd:00 5931062 /lib/libthread_db-1.0.so
    afeb6000-afeb7000 r-xp 00004000 fd:00 5931062 /lib/libthread_db-1.0.so
    afeb7000-afeb8000 rwxp 00005000 fd:00 5931062 /lib/libthread_db-1.0.so
    afecb000-afede000 r-xp 00000000 fd:00 16777249 /usr/java/jdk1.6.0_03/jre/lib/i386/libnet.so
    afede000-afedf000 rwxp 00013000 fd:00 16777249 /usr/java/jdk1.6.0_03/jre/lib/i386/libnet.so
    afedf000-afefe000 r-xs 00152000 fd:00 16810648 /usr/java/jdk1.6.0_03/lib/sa-jdi.jar
    afefe000-aff5b000 r-xs 00b3c000 fd:00 16811549 /usr/java/jdk1.6.0_03/lib/tools.jar
    aff5b000-aff5c000 ---p aff5b000 00:00 0
    aff5c000-affdc000 rwxp aff5c000 00:00 0
    affdc000-affdf000 ---p affdc000 00:00 0
    affdf000-b002d000 rwxp affdf000 00:00 0
    b002d000-b0030000 ---p b002d000 00:00 0
    b0030000-b00ae000 rwxp b0030000 00:00 0
    b00ae000-b00b1000 ---p b00ae000 00:00 0
    b00b1000-b012f000 rwxp b00b1000 00:00 0
    b012f000-b0132000 ---p b012f000 00:00 0
    b0132000-b0180000 rwxp b0132000 00:00 0
    b0180000-b0380000 r-xp 00000000 fd:00 15535906 /usr/lib/locale/locale-archive
    b0380000-b0383000 ---p b0380000 00:00 0
    b0383000-b03d1000 rwxp b0383000 00:00 0
    b03d1000-b03d4000 ---p b03d1000 00:00 0
    b03d4000-b0422000 rwxp b03d4000 00:00 0
    b0422000-b0423000 ---p b0422000 00:00 0
    b0423000-b04d3000 rwxp b0423000 00:00 0
    b04d3000-b064f000 r-xs 02c8f000 fd:00 16777319 /usr/java/jdk1.6.0_03/jre/lib/rt.jar
    b064f000-b0650000 ---p b064f000 00:00 0
    b0650000-b06d0000 rwxp b0650000 00:00 0
    b06d0000-b06d1000 ---p b06d0000 00:00 0
    b06d1000-b0751000 rwxp b06d1000 00:00 0
    b0751000-b0752000 ---p b0751000 00:00 0
    b0752000-b07d2000 rwxp b0752000 00:00 0
    b07d2000-b07d3000 ---p b07d2000 00:00 0
    b07d3000-b0853000 rwxp b07d3000 00:00 0
    b0853000-b0854000 ---p b0853000 00:00 0
    b0854000-b08d4000 rwxp b0854000 00:00 0
    b08d4000-b08d5000 ---p b08d4000 00:00 0
    b08d5000-b0955000 rwxp b08d5000 00:00 0
    b0955000-b0956000 ---p b0955000 00:00 0
    b0956000-b09d6000 rwxp b0956000 00:00 0
    b09d6000-b09d7000 ---p b09d6000 00:00 0
    b09d7000-b0a5f000 rwxp b09d7000 00:00 0
    b0a5f000-b0a77000 rwxp b0a5f000 00:00 0
    b0a77000-b0aa1000 rwxp b0a77000 00:00 0
    b0aa1000-b0c3f000 rwxp b0aa1000 00:00 0
    b0c3f000-b0c47000 rwxp b0c3f000 00:00 0
    b0c47000-b0c5f000 rwxp b0c47000 00:00 0
    b0c5f000-b0c89000 rwxp b0c5f000 00:00 0
    b0c89000-b0e26000 rwxp b0c89000 00:00 0
    b0e26000-b0e2c000 rwxp b0e26000 00:00 0
    b0e2c000-b0e5f000 rwxp b0e2c000 00:00 0
    b0e5f000-b1e60000 rwxp b0e5f000 00:00 0
    b1e60000-b4e60000 rwxp b1e60000 00:00 0
    b4e60000-ba160000 rwxp b4e60000 00:00 0
    ba160000-edca0000 rwxp ba160000 00:00 0
    edca0000-ee6f0000 rwxp edca0000 00:00 0
    ee6f0000-f4e60000 rwxp ee6f0000 00:00 0
    f4e63000-f4e6c000 rwxp f4e63000 00:00 0
    f4e6c000-f4f23000 rwxp f4e6c000 00:00 0
    f4f23000-f5163000 rwxp f4f23000 00:00 0
    f5163000-f7f23000 rwxp f5163000 00:00 0
    f7f23000-f7f32000 r-xp 00000000 fd:00 16777245 /usr/java/jdk1.6.0_03/jre/lib/i386/libzip.so
    f7f32000-f7f34000 rwxp 0000e000 fd:00 16777245 /usr/java/jdk1.6.0_03/jre/lib/i386/libzip.so
    f7f34000-f7f57000 r-xp 00000000 fd:00 16777241 /usr/java/jdk1.6.0_03/jre/lib/i386/libjava.so
    f7f57000-f7f59000 rwxp 00023000 fd:00 16777241 /usr/java/jdk1.6.0_03/jre/lib/i386/libjava.so
    f7f59000-f7f62000 r-xp 00000000 fd:00 5931048 /lib/libnss_files-2.5.so
    f7f62000-f7f63000 r-xp 00008000 fd:00 5931048 /lib/libnss_files-2.5.so
    f7f63000-f7f64000 rwxp 00009000 fd:00 5931048 /lib/libnss_files-2.5.so
    f7f64000-f7f77000 r-xp 00000000 fd:00 5931145 /lib/libnsl-2.5.so
    f7f77000-f7f78000 r-xp 00012000 fd:00 5931145 /lib/libnsl-2.5.so
    f7f78000-f7f79000 rwxp 00013000 fd:00 5931145 /lib/libnsl-2.5.so
    f7f79000-f7f7b000 rwxp f7f79000 00:00 0
    f7f82000-f7f8d000 r-xp 00000000 fd:00 16777240 /usr/java/jdk1.6.0_03/jre/lib/i386/libverify.so
    f7f8d000-f7f8e000 rwxp 0000b000 fd:00 16777240 /usr/java/jdk1.6.0_03/jre/lib/i386/libverify.so
    f7f8e000-f7f91000 ---p f7f8e000 00:00 0
    f7f91000-f7fe1000 rwxp f7f91000 00:00 0
    f7fe1000-f7fe8000 r-xp 00000000 fd:00 16777243 /usr/java/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
    f7fe8000-f7fea000 rwxp 00006000 fd:00 16777243 /usr/java/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
    f7fec000-f7ff4000 rwxs 00000000 fd:00 19562502 /tmp/hsperfdata_omnitrak/3653
    f7ff4000-f7ffa000 r-xp 00000000 fd:00 16777227 /usr/java/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
    f7ffa000-f7ffb000 rwxp 00006000 fd:00 16777227 /usr/java/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
    f7ffb000-f7ffc000 rwxp f7ffb000 00:00 0
    f7ffc000-f7ffd000 r-xp f7ffc000 00:00 0
    f7ffd000-f7ffe000 rwxp f7ffd000 00:00 0
    ff9fb000-ffa03000 rwxp ff9fb000 00:00 0 [stack]
    ffffe000-fffff000 r-xp ffffe000 00:00 0
    VM Arguments:
    jvm_args: -Dapplication.home=/usr/java/jdk1.6.0_03
    java_command: com.sun.tools.example.debug.tty.TTY -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=/usr/java/jdk/bin/java,core=core.25602
    Launcher Type: SUN_STANDARD
    Environment Variables:
    PATH=/usr/java/jdk/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin
    LD_LIBRARY_PATH=/usr/java/jdk1.6.0_03/jre/lib/i386/server:/usr/java/jdk1.6.0_03/jre/lib/i386:/usr/java/jdk1.6.0_03/jre/../lib/i386
    SHELL=/bin/bash
    Signal Handlers:
    SIGSEGV: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGBUS: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGFPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGPIPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGILL: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
    SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
    SIGHUP: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGINT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGQUIT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGTERM: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
    --------------- S Y S T E M ---------------
    OS:Red Hat Enterprise Linux Client release 5.1 (Tikanga)
    uname:Linux 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT 2007 x86_64
    libc:glibc 2.5 NPTL 2.5
    rlimit: STACK 10240k, CORE 0k, NPROC 53248, NOFILE 1024, AS infinity
    load average:0.07 0.22 0.42
    CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
    Memory: 4k page, physical 6113940k(245496k free), swap 2097144k(2097144k free)
    vm_info: Java HotSpot(TM) Server VM (1.6.0_03-b05) for linux-x86, built on Sep 24 2007 22:32:39 by "java_re" with gcc 3.2.1-7a (J2SE release)

    Thank you for your responds!
    I'm not trying at all to transfer the core to a different system. I'm debugging on the same linux red hat box where the cores where produced and I'm using the JDB version from the same JDK that was used to run the app.
    I'm wondering what makes you think that I'm possibly mixing core files?
    Here is the output that JDB generates when I define LIBSAPROC_DEBUG=1. This is the case when JDB crashes:
    $ jdb -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=/usr/java/jdk/bin/java,core=core.23850
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24310
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x0
    libsaproc DEBUG: ebx = 0x5d2a
    libsaproc DEBUG: ecx = 0x5ef6
    libsaproc DEBUG: edx = 0x6
    libsaproc DEBUG: esp = 0x324fd0e4
    libsaproc DEBUG: ebp = 0x324fd0e4
    libsaproc DEBUG: esi = 0x324fd19c
    libsaproc DEBUG: edi = 0x78eff4
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 3 and n_descsz = 124
    libsaproc DEBUG: Note header with n_type = 6 and n_descsz = 144
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 27070
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffe00
    libsaproc DEBUG: ebx = 0xa
    libsaproc DEBUG: ecx = 0x312edad8
    libsaproc DEBUG: edx = 0x33f4d1a4
    libsaproc DEBUG: esp = 0x312edac0
    libsaproc DEBUG: ebp = 0x312edac0
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x2000
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 27063
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffe00
    libsaproc DEBUG: ebx = 0xa
    libsaproc DEBUG: ecx = 0x334fccd8
    libsaproc DEBUG: edx = 0x33f4d1a4
    libsaproc DEBUG: esp = 0x334fccc0
    libsaproc DEBUG: ebp = 0x334fccc0
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x2000
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 1754
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x32baab38
    libsaproc DEBUG: ecx = 0x1
    libsaproc DEBUG: edx = 0x6ddd00
    libsaproc DEBUG: esp = 0x32baaaf0
    libsaproc DEBUG: ebp = 0x32baaaf0
    libsaproc DEBUG: esi = 0x1eed0
    libsaproc DEBUG: edi = 0x78eff4
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24325
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x834486c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x306bf
    libsaproc DEBUG: esp = 0x32bfdda8
    libsaproc DEBUG: ebp = 0x32bfdda8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x306bf
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24319
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x831e8cc
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x2d49f7
    libsaproc DEBUG: esp = 0x33259cb0
    libsaproc DEBUG: ebp = 0x33259cb0
    libsaproc DEBUG: esi = 0x33259cc4
    libsaproc DEBUG: edi = 0x2d49f7
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24318
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x83783a4
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x38dd3
    libsaproc DEBUG: esp = 0x3330ab30
    libsaproc DEBUG: ebp = 0x3330ab30
    libsaproc DEBUG: esi = 0x3330ab44
    libsaproc DEBUG: edi = 0x38dd3
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24317
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x1
    libsaproc DEBUG: ebx = 0x827bb60
    libsaproc DEBUG: ecx = 0x1
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x3335bb0c
    libsaproc DEBUG: ebp = 0x3335bb0c
    libsaproc DEBUG: esi = 0x3335bbb8
    libsaproc DEBUG: edi = 0x827bb60
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24316
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8082d14
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x33d5ca98
    libsaproc DEBUG: ebp = 0x33d5ca98
    libsaproc DEBUG: esi = 0x33d5caac
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24315
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8378204
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x334adac8
    libsaproc DEBUG: ebp = 0x334adac8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24314
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x19
    libsaproc DEBUG: ebx = 0x33f164cc
    libsaproc DEBUG: ecx = 0x9b
    libsaproc DEBUG: edx = 0x39f99940
    libsaproc DEBUG: esp = 0x320f9a14
    libsaproc DEBUG: ebp = 0x1e
    libsaproc DEBUG: esi = 0x2
    libsaproc DEBUG: edi = 0x39f975a0
    libsaproc DEBUG: eip = 0x33f0e054
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24313
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x39c534e0
    libsaproc DEBUG: ebx = 0x33f164cc
    libsaproc DEBUG: ecx = 0x321fabba
    libsaproc DEBUG: edx = 0x6
    libsaproc DEBUG: esp = 0x321faa70
    libsaproc DEBUG: ebp = 0x321faa7c
    libsaproc DEBUG: esi = 0x2
    libsaproc DEBUG: edi = 0x39c53478
    libsaproc DEBUG: eip = 0x33f1028e
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24312
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x29
    libsaproc DEBUG: ebx = 0x39bd4780
    libsaproc DEBUG: ecx = 0x1
    libsaproc DEBUG: edx = 0x2400d1a2
    libsaproc DEBUG: esp = 0x322fbc50
    libsaproc DEBUG: ebp = 0x322fbc7c
    libsaproc DEBUG: esi = 0x33f167a8
    libsaproc DEBUG: edi = 0xf9000607
    libsaproc DEBUG: eip = 0x33f0ef54
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24311
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x827ac04
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x137ee7
    libsaproc DEBUG: esp = 0x323fcd28
    libsaproc DEBUG: ebp = 0x323fcd28
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x137ee7
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24309
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x6
    libsaproc DEBUG: ebx = 0x3a5c0970
    libsaproc DEBUG: ecx = 0x2
    libsaproc DEBUG: edx = 0xb
    libsaproc DEBUG: esp = 0x325febd0
    libsaproc DEBUG: ebp = 0x3a5c1cdc
    libsaproc DEBUG: esi = 0x6
    libsaproc DEBUG: edi = 0x4
    libsaproc DEBUG: eip = 0x33f0ef06
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24308
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x5
    libsaproc DEBUG: ebx = 0x3a98cb48
    libsaproc DEBUG: ecx = 0x2
    libsaproc DEBUG: edx = 0x9
    libsaproc DEBUG: esp = 0x32cfea50
    libsaproc DEBUG: ebp = 0x3a98dde8
    libsaproc DEBUG: esi = 0x5
    libsaproc DEBUG: edi = 0x5
    libsaproc DEBUG: eip = 0x33f0f084
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24307
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0x8
    libsaproc DEBUG: ebx = 0x3a1fd104
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x6
    libsaproc DEBUG: esp = 0x3345c984
    libsaproc DEBUG: ebp = 0x3345c984
    libsaproc DEBUG: esi = 0x29
    libsaproc DEBUG: edi = 0x0
    libsaproc DEBUG: eip = 0x33f0f210
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24304
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x82ee0ac
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x332aad90
    libsaproc DEBUG: ebp = 0x332aad90
    libsaproc DEBUG: esi = 0x332aada4
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24015
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x856427c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x33b5ca90
    libsaproc DEBUG: ebp = 0x33b5ca90
    libsaproc DEBUG: esi = 0x33b5caa4
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24014
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x818b8e4
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x3
    libsaproc DEBUG: esp = 0x33bada98
    libsaproc DEBUG: ebp = 0x33bada98
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x3
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24013
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffe00
    libsaproc DEBUG: ebx = 0x5
    libsaproc DEBUG: ecx = 0x33bfedd0
    libsaproc DEBUG: edx = 0x33f4d1a4
    libsaproc DEBUG: esp = 0x33bfedb8
    libsaproc DEBUG: ebp = 0x33bfedb8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x827e400
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24011
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x828951c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x33dadcd8
    libsaproc DEBUG: ebp = 0x33dadcd8
    libsaproc DEBUG: esi = 0x33dadcec
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 24010
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x849caac
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x33dfec68
    libsaproc DEBUG: ebp = 0x33dfec68
    libsaproc DEBUG: esi = 0x33dfec7c
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23868
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x80c213c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x34090f78
    libsaproc DEBUG: ebp = 0x34090f78
    libsaproc DEBUG: esi = 0x34090f8c
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23867
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x819e294
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0x340e2018
    libsaproc DEBUG: ebp = 0x340e2018
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23866
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8199a5c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x434
    libsaproc DEBUG: esp = 0x34162e48
    libsaproc DEBUG: ebp = 0x34162e48
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x434
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23865
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8199a5c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x432
    libsaproc DEBUG: esp = 0x341e3ec8
    libsaproc DEBUG: ebp = 0x341e3ec8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x432
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23864
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x65e80a0
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x0
    libsaproc DEBUG: esp = 0x34234fb0
    libsaproc DEBUG: ebp = 0x34234fb0
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0xffc
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23863
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x818ba8c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x289
    libsaproc DEBUG: esp = 0x34485de0
    libsaproc DEBUG: ebp = 0x34485de0
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x289
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23862
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x81887d4
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x2b3
    libsaproc DEBUG: esp = 0x344d6c90
    libsaproc DEBUG: ebp = 0x344d6c90
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x2b3
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23861
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x31e0548c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x3
    libsaproc DEBUG: esp = 0x345580d8
    libsaproc DEBUG: ebp = 0x345580d8
    libsaproc DEBUG: esi = 0x345580ec
    libsaproc DEBUG: edi = 0x3
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23860
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e9b
    libsaproc DEBUG: esp = 0x34784f68
    libsaproc DEBUG: ebp = 0x34784f68
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e9b
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23859
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e9a
    libsaproc DEBUG: esp = 0x34805fe8
    libsaproc DEBUG: ebp = 0x34805fe8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e9a
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23858
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e9c
    libsaproc DEBUG: esp = 0x34886e68
    libsaproc DEBUG: ebp = 0x34886e68
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e9c
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23857
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e99
    libsaproc DEBUG: esp = 0x34907ee8
    libsaproc DEBUG: ebp = 0x34907ee8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e99
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23856
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e98
    libsaproc DEBUG: esp = 0x34989168
    libsaproc DEBUG: ebp = 0x34989168
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e98
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23855
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e97
    libsaproc DEBUG: esp = 0x34a0a1e8
    libsaproc DEBUG: ebp = 0x34a0a1e8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e97
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23854
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e96
    libsaproc DEBUG: esp = 0x34a8b068
    libsaproc DEBUG: ebp = 0x34a8b068
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e96
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23853
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x8096674
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x161e95
    libsaproc DEBUG: esp = 0x34b0c0e8
    libsaproc DEBUG: ebp = 0x34b0c0e8
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x161e95
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23852
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0x33e5e19c
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x1
    libsaproc DEBUG: esp = 0xf7fde228
    libsaproc DEBUG: ebp = 0xf7fde228
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x1
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
    libsaproc DEBUG: got integer regset for lwp 23850
    libsaproc DEBUG: integer regset
    libsaproc DEBUG: eax = 0xfffffffc
    libsaproc DEBUG: ebx = 0xf7fdebd8
    libsaproc DEBUG: ecx = 0x0
    libsaproc DEBUG: edx = 0x5d2c
    libsaproc DEBUG: esp = 0xffb93630
    libsaproc DEBUG: ebp = 0xffb93630
    libsaproc DEBUG: esi = 0x0
    libsaproc DEBUG: edi = 0x7a8ff4
    libsaproc DEBUG: eip = 0xffffe410
    libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
    libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
    libsaproc DEBUG: ELF interpreter /lib/ld-linux.so.2
    libsaproc DEBUG: address of _DYNAMIC is 0x8052548
    libsaproc DEBUG: ---- sorted virtual address map ----
    libsaproc DEBUG: base = 0x64f000 size = 4096
    libsaproc DEBUG: base = 0x650000 size = 4096
    libsaproc DEBUG: base = 0x78d000 size = 8192
    libsaproc DEBUG: base = 0x78f000 size = 4096
    libsaproc DEBUG: base = 0x790000 size = 12288
    libsaproc DEBUG: base = 0x7a8000 size = 4096
    libsaproc DEBUG: base = 0x7a9000 size = 4096
    libsaproc DEBUG: base = 0x7aa000 size = 8192
    libsaproc DEBUG: base = 0x7b0000 size = 4096
    libsaproc DEBUG: base = 0x7b1000 size = 4096
    libsaproc DEBUG: base = 0x879000 size = 4096
    libsaproc DEBUG: base = 0x87a000 size = 4096
    libsaproc DEBUG: base = 0x884000 size = 4096
    libsaproc DEBUG: base = 0x885000 size = 4096
    libsaproc DEBUG: base = 0xc37000 size = 16384
    libsaproc DEBUG: base = 0xc3b000 size = 4096
    libsaproc DEBUG: base = 0xc3c000 size = 24576
    libsaproc DEBUG: base = 0xd38000 size = 4096
    libsaproc DEBUG: base = 0x6000000 size = 5898240
    libsaproc DEBUG: base = 0x65a0000 size = 241664
    libsaproc DEBUG: base = 0x65db000 size = 4329472
    libsaproc DEBUG: base = 0x8048000 size = 38100
    libsaproc DEBUG: base = 0x8052000 size = 4096
    libsaproc DEBUG: base = 0x8053000 size = 14032896
    libsaproc DEBUG: base = 0x30f00000 size = 1007616
    libsaproc DEBUG: base = 0x31100000 size = 1048576
    libsaproc DEBUG: base = 0x312a0000 size = 12288
    libsaproc DEBUG: base = 0x312a3000 size = 319488
    libsaproc DEBUG: base = 0x3133a000 size = 16384
    libsaproc DEBUG: base = 0x31344000 size = 753664
    libsaproc DEBUG: base = 0x313fc000 size = 16384
    libsaproc DEBUG: base = 0x31400000 size = 929792
    libsaproc DEBUG: base = 0x31500000 size = 1028096
    libsaproc DEBUG: base = 0x31600000 size = 966656
    libsaproc DEBUG: base = 0x31700000 size = 1028096
    libsaproc DEBUG: base = 0x31800000 size = 991232
    libsaproc DEBUG: base = 0x31900000 size = 1044480
    libsaproc DEBUG: base = 0x31a00000 size = 1032192
    libsaproc DEBUG: base = 0x31b00000 size = 1032192
    libsaproc DEBUG: base = 0x31c00000 size = 1003520
    libsaproc DEBUG: base = 0x31d51000 size = 319488
    libsaproc DEBUG: base = 0x31df9000 size = 28672
    libsaproc DEBUG: base = 0x31e00000 size = 1048576
    libsaproc DEBUG: base = 0x31f03000 size = 552960
    libsaproc DEBUG: base = 0x31f8a000 size = 20480
    libsaproc DEBUG: base = 0x31f90000 size = 331776
    libsaproc DEBUG: base = 0x31fe1000 size = 8192
    libsaproc DEBUG: base = 0x31ffa000 size = 12288
    libsaproc DEBUG: base = 0x31ffd000 size = 1040384
    libsaproc DEBUG: base = 0x320fb000 size = 12288
    libsaproc DEBUG: base = 0x320fe000 size = 1040384
    libsaproc DEBUG: base = 0x321fc000 size = 12288
    libsaproc DEBUG: base = 0x321ff000 size = 1040384
    libsaproc DEBUG: base = 0x322fd000 size = 12288
    libsaproc DEBUG: base = 0x32300000 size = 1040384
    libsaproc DEBUG: base = 0x323fe000 size = 12288
    libsaproc DEBUG: base = 0x32401000 size = 1040384
    libsaproc DEBUG: base = 0x324ff000 size = 12288
    libsaproc DEBUG: base = 0x32502000 size = 1957888
    libsaproc DEBUG: base = 0x32700000 size = 1024000
    libsaproc DEBUG: base = 0x32800000 size = 2072576
    libsaproc DEBUG: base = 0x32a00000 size = 1040384
    libsaproc DEBUG: base

  • Value type exception causes core dump

    Hi,
    Here is the situation: Session EJB (SynchronousAdapterBean) running on WebLogic
    7.0 is being called by C++ client using Tuxedo 8.1 Solaris 8. The SynchronousAdapterBean
    has a find method which throws a user defined exception (SynchronousAdapterException)
    resulting in a core dump.
    I have read through much documentation on the newsgroups, edocs.bea.com, and
    the examples coming with WebLogic.
    Here some of the things I did:
    1.
    When using the 'idl' command to generate the C++ code, I did not forget to use
    a '-i' to generate the implementation files: SynchronousAdapterException_i.cpp
    and SynchronousAdapterException_i.h.
    In my "play with it to make it work" phase, I also did this for: SynchronousAdapterEx_i.cpp
    and SynchronousAdapterEx_i.h.
    2.
    In my C++ client, I did not forget to register the factory as such:
    orb->register_value_factory
    ((char* const)com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException->id(),
    (CORBA::ValueFactory)
    new com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory());
    This seemed to work because I actually put debug cout statements in the 'com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory'
    in the file SynchronousAdapterEx_i.cpp and it confirmed that it was constructed
    and the reference count was incremented.
    3.
    I know for sure that it is a 'SynchronousAdapterException' being thrown on the
    server side because all the find method does it this point is:
    throw new SynchronousAdapterException("test1");
    Questions:
    1. I read at a few places that one only has to register the "most derived" class
    being thrown (in my case 'SynchronousAdapterException'). What does one do with
    all the other exceptions generated:
    EJBException_c.h
    EJBException_c.cpp
    EJBEx_c.h
    EJBEx_c.cpp
    CreateEx_c.h
    CreateEx_c.cpp
    CreateException_c.h
    CreateException_c.cpp
    RemoveEx_c.h
    RemoveEx_c.cpp
    RemoveException_c.h
    RemoveException_c.cpp
    RuntimeEx_c.h
    RuntimeEx_c.cpp
    RuntimeException_c.cpp
    RuntimeException_c.h
    SynchronousAdapterEx_c.cpp
    SynchronousAdapterEx_c.h
    SynchronousAdapterEx_i.cpp
    SynchronousAdapterEx_i.h
    Exc.cpp
    Exc.h
    Exceptionc.cpp
    Exceptionc.h
    2. What step could I have missed?
    Alex

    Hi Andy,
    1.
    Well no new member classes in SynchronousAdapterException it just looks like this:
    public class SynchronousAdapterException extends Exception {
    public SynchronousAdapterException() {
    super();
    Not available in 1.3.1, but is available in 1.4
    public SynchronousAdapterException(String message, Throwable ex) {
    super(message, ex);
    public SynchronousAdapterException(String message) {
    super(message);
    Not available in 1.3.1, but is available in 1.4
    public SynchronousAdapterException(Throwable ex) {
    super(ex);
    2.
    We are using:
    java version "1.3.1_03"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
    Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)
    3.
    dbx produces the following, anything ring a bell?
    Reading libdl.so.1
    Reading libaio.so.1
    Reading libmp.so.2
    Reading libc_psr.so.1
    Reading liborbiiop.so.71
    Reading liborbtcp.so.71
    detected a multithreaded program
    t@2 (l@2) terminated by signal ABRT (Abort)
    0xfec9bbd4: lwpkill+0x0008: bgeu,a lwpkill+0x1c
    Current function is operator>>
    218 mb.UnMarshalValue(::com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException,
    obj);
    (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
    current thread: t@2
    [1] lwpkill(0x0, 0x2, 0x0, 0x6, 0x197f0, 0x4c6e0), at 0xfec9bbd4
    [2] raise(0x6, 0x0, 0xffffffff, 0xc00cc, 0x8, 0xfee355c0), at 0x4c6e8
    [3] abort(0xd2040, 0xbeaf8, 0xff3b2aac, 0xfee34684, 0x15398, 0xfee34874), at
    0x4c6a8
    [4] __Cimpl::ex_terminate(0x0, 0x0, 0xfee4a500, 0xff1edf90, 0xff09ecd0, 0x1),
    at 0xfee34684
    ---- hidden frames, use 'where -h' to see them all ----
    [6] OBB::MarshalBuf::UnMarshalValue(0xfeaf9a28, 0xc9dd8, 0xfeaf99b0, 0xff1edf90,
    0xff1edfd0, 0xfed2ebb8), at 0xff0a3980
    =>[7] operator>>(mb = CLASS, obj = CLASS), line 218 in "SynchronousAdapterExc.cpp"
    [8] _tcr_com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterEx_unmarsh(mh =
    0xce520, obj = 0xfeaf9b7c, flags = 130U), line 259 in "SynchronousAdapterEx_c.cpp"
    [9] TCInterpreter::DecodeByTypeCode(0x16, 0xff1d674c, 0xfeaf9b7c, 0xce520, 0x82,
    0xfeaf9b07), at 0xff0f3aec
    [10] TCInterpreter::DecodeById(0xcbaa0, 0xcf230, 0xfeaf9b7c, 0xce520, 0x82,
    0xfeaf9f98), at 0xff0f3c94
    [11] ReplyMessage::DecodeMessageBody(0x18000, 0xcd820, 0xfeaf9f98, 0xbf358,
    0xfebcffb0, 0xfed2ebb8), at 0xff0e1938
    [12] GIOPMessage::DecodeBody(0xce240, 0xfeaf9f98, 0xff0dd494, 0xff0dd494, 0xffffffd0,
    0xfeb93e24), at 0xff0c23a0
    [13] IiopProtocol::Reply(0xd0958, 0xce240, 0xce148, 0xfeaf9f98, 0x100, 0xfebd0010),
    at 0xfeb94064
    [14] IiopMsgReceiver::MsgReceived(0xca5a0, 0xce240, 0xce148, 0xfeaf9f98, 0x0,
    0xfeaf9f98), at 0xfeb9bc74
    [15] GiopMessageProtocol::MsgReceived(0xcb358, 0xfeaf9dd8, 0xd1160, 0xfeaf9f98,
    0x0, 0xfeaf9f98), at 0xfebac6fc
    [16] MessageManager::RecvMsgFirstTime(0xcf8c0, 0xce240, 0xd1160, 0xcb358, 0xd11d0,
    0xfeaf9f98), at 0xfebab1b0
    [17] MessageManager::AvailableForRecvMsg(0xcf8c0, 0xd1160, 0xcb358, 0xfeaf9f98,
    0x3e8, 0xd1170), at 0xfebaa030
    [18] ChannelManager::DoReadWork(0xff1d674c, 0xfebd0038, 0xd1160, 0x0, 0x0, 0xcfd58),
    at 0xfeba54dc
    [19] ChannelManager::DoIt(0xcb3b0, 0xfeaf9f98, 0x0, 0xfebcffd0, 0xcfda0, 0xfebcffd0),
    at 0xfeba0750
    [20] WorkerManager::DoWorkerThread(0x0, 0xca648, 0xfeaf9f98, 0xcfda0, 0xfeba9924,
    0x0), at 0xfeba7894
    [21] WorkerThread(0xcfd98, 0xfeafa000, 0x0, 0x0, 0x0, 0x0), at 0xfeba9974
    (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx)
    Thanks,
    Alex
    Andy Piper <[email protected]> wrote:
    "Alex" <[email protected]> writes:
    It sounds like you have done all the right steps. More comments in-line:
    1.
    When using the 'idl' command to generate the C++ code, I did not forgetto use
    a '-i' to generate the implementation files: SynchronousAdapterException_i.cpp
    and SynchronousAdapterException_i.h. Ok.
    In my "play with it to make it work" phase, I also did this for: SynchronousAdapterEx_i.cpp
    and SynchronousAdapterEx_i.h.This should not be necessary - XXXEx is an IDL exception.
    2.
    In my C++ client, I did not forget to register the factory as such:
    orb->register_value_factory
    ((char* const)com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException->id(),
    (CORBA::ValueFactory)
    new com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory());Ok. What does the Exception actually look like in Java? (Incidentally
    the _i file creates a useful helper function called _register() which
    will do this step for you). Did you register all member classes? You
    are correct about most derived types being the important ones, but you
    need to also register member classes if they are not standard.
    This seemed to work because I actually put debug cout statements inthe 'com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory'
    in the file SynchronousAdapterEx_i.cpp and it confirmed that it wasconstructed
    and the reference count was incremented.
    3.
    I know for sure that it is a 'SynchronousAdapterException' being thrownon the
    server side because all the find method does it this point is:
    throw new SynchronousAdapterException("test1");Ok (incidentally you are not running the server on JDK 1.4 are
    you. This would cause problems).
    Questions:
    1. I read at a few places that one only has to register the "most derived"class
    being thrown (in my case 'SynchronousAdapterException'). What doesone do with
    Yes.
    all the other exceptions generated:These are just needed at compile time so that you don't get undefined
    symbols.
    2. What step could I have missed?Its not clear. You should try running in a debugger and seeing where
    its falling over.
    andy

  • Dump complete java VM state as core dump (not via OS) possible?

    Hi everyone,
    I've a problem debugging an application.
    Background: Sometimes my application comes to a very unlikely state, which at the moment results in an error message. The stack trace alone has no great value, since this state is cause by the interaction of more than one thread. The state is resolved throwing an exception, the program continues normally.
    Goal: If I reach this state, I want to suspend the application, dump the complete state of all java threads, objects, ... (complete java memory core dump) to analyse it later.
    Question: Is there a possibility to generate such dumps?
    Just thinking:
    One posibility would be, to send a signal from the vm to some external program (e.g. udp packet), this program attaches a standard OS-level debugger (e.g. gdb under linux), dumps the core, resumes app, detach. But I guess reconstruction of internal VM state from complete dump is rather hard, is it?
    I've looked at jdb, to see if it has some java-core-dump functions, but it seems not to be so. Are there alternative implementations, or helper scripts that make jdb loop over all java object addresses and dump them?
    Does someone known about the jdb remote debugging interface? Is the protocol public, can I implement such a feature on myself?

    Hi everyone,
    I was looking for a way to dump the complete state of a JVM (all runing threads, objects, ...) and afterwards to analize the dumped data. I have found a thread(http://forum.java.sun.com/thread.jspa?threadID=735052) here in the forums with some explainations how this could be done using the Java 2 sdk 1.5.0 - troubleshooting tools (http://java.sun.com/j2se/1.5.0/docs/tooldocs/experimentaltools.html).
    I've made a small application, which starts a thread and just prints out continously some messages to the console.
    After that I attached with gdb to the running process as described, and generated a core file.
    Unfortunatelly on calling jdsadebugd with the core dump it throws the following exception:
    jsadebugd /..../jdk1.5.0_07/bin/java core.18294 DebServ
    Attaching to core core.18294 from executable /.../jdk1.5.0_07/bin/java and starting RMI services, please wait...
    Error attaching to core file or starting server: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:258)
    at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:624)
    at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:610)
    at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:323)
    at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:298)
    at sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:234)
    at sun.jvm.hotspot.DebugServer.run(DebugServer.java:94)
    at sun.jvm.hotspot.DebugServer.main(DebugServer.java:29)
    at sun.jvm.hotspot.jdi.SADebugServer.main(SADebugServer.java:46)
    Even if I try to print the shared objects mapping with jmap it fails with the following message:
    jmap /.../jdk1.5.0_07/bin/java core.18294
    Attaching to core core.18294 from executable /.../jdk1.5.0_07/bin/java, please wait...
    Error attaching to core file: Can't attach to the core file
    Does anyone have an idea what goes wrong here?

  • Webcenter crashing with core dump

    Hi All,
    Once in a while Webcenter(11.1.1.5) is crashing and generating core dump and the error message is same evertime. We tried to research on addPartialTriggerListeners and found this kind of behaviour is a bug in apache trinidad version 1.2.5-core and is fixed in 1.2.7-core. But the webcenter we are using as version 1.2.12. Also the issue seems to be comming from webcenter/adf framework itself as none of our code uses addPartialTriggerListeners.
    Please help us resolve this issue as we are getting this issue in our production environment and we need to fix this asap.
    # A fatal error has been detected by the Java Runtime Environment:
    # SIGSEGV (0xb) at pc=0xffffffff7318caf0, pid=19921, tid=149
    # JRE version: 6.0_29-b11
    # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode solaris-sparc compressed oops)
    *# Problematic frame:*
    +*# J  org.apache.myfaces.trinidadinternal.context.RequestContextImpl.addPartialTriggerListeners(Ljavax/faces/component/UIComponent;[Ljava/lang/String;)V*#+
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    --------------- T H R E A D ---------------
    Current thread (0x00000001145ba000): JavaThread "[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_in_Java, id=149, stack(0xfffffffea6800000,0xfffffffea6900000)]
    siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
    Registers:
    G1=0xffffffff503d5098 G2=0x00000001145ba000 G3=0xffffffff73516254 G4=0x00000000000000d1
    Thanks

    Oracle Support has a thread and work around for this.
    DocID 1514563.1
    Applies to:
    Oracle WebCenter Portal - Version 11.1.1.5.0 and later
    Information in this document applies to any platform.
    Purpose
    Java HotSpot Virtual Machine, a core component of Oracle's Java SE platform, known to core dump (resulting in a server crash) while optimizing certain methods in Oracle WebCenter.
    If you can switch to JRockit you can get around it also. Otherwise follow the note and setup the appropriate pre-compile excludes in your WC startup script.

  • Linux 6.1/Oracle 8.1.5 Pro C compilation core dumps

    Linux installation did not place stdarg.h or stddef.h in the /usr/include directory for some reaon. I located different copies in other directories and have created symobolic links to them all in the end. BUT all result in the following error when I attempt to make sample1.pc in $ORACLE_HOME/precomp/demo/proc. Has anyone got any ideas how I can fix this problem.
    Yours hopefully Kev
    make -f demo_proc.mk sample1
    gmake -f /oracle/app/oracle/product/8.1.5/precomp/demo/proc/demo_proc.mk
    OBJS=sample1.o EXE=sample1 build
    gmake[1]: Entering directory `/oracle/app/oracle/product/8.1.5/precomp/demo/proc'
    proc iname=sample1
    Pro*C/C++: Release 8.1.5.0.0 - Production on Sun Jan 9 17:02:05 2000
    (c) Copyright 1999 Oracle Corporation. All rights reserved.
    System default option values taken from:
    /oracle/app/oracle/product/8.1.5/precomp/admin/pcscfg.cfg
    gmake[1]: *** [sample1.o] Segmentation fault (core dumped)
    gmake[1]: Leaving directory `/oracle/app/oracle/product/8.1.5/precomp/demo/proc'
    make: *** [sample1] Error 2
    null

    Thanks for your input. But having investiagted further I have made progress.
    On one of the FAQ docs listed throughout the Linux Forum I found an example of what should be in the pcscfg.cfg file. Once this was in place I then had, /usr/bin/ld cannot find -laio (or the file /usr/lib/libaio.a). To get a clean(ish) compile, I created a symbolic link from libc.a to libaio.a which is crude but was effective. I had a working Pro C exe.
    I understand that the second patch solves the libaio.a prob as well as others. But a colleague has installed it and had to regress it, due to more damaging problems he listed but I cannot recall at this time.
    Thanks again.

  • OCILogon2: Core Dump

    I'm having issues with the OCILogon2() API. The system is Solaris 8
    running Oracle 9.0.1; the application is written in C. In normal
    operation, the application functions with no issues: queries can be
    made, etc, so this isn't an issue of getting it up and running; it
    already works, but now a bug has been revealed.
    The original thing which pointed out the problem is the fact that a
    firewall in front of the Oracle database was timing out and dropping
    the client connection after 60-minutes of inactivity. (Note that
    the firewall problem is now a non-issue, but the error it uncovered
    is a serious one, so I'd like to still find a solution to that in
    case some other situation causes a similar problem.)
    Eventually, the client would receive the ORA-03113 "end-of-file on
    communication channel" error when calling OCILogon2() if attempting
    to do a login/query after a period of inactivity because the firewall
    had dropped the connection. The application is multi-threaded and is
    using Connection Pooling, so if another thread attempted to login after
    this error was received, the OCILogon2() API would core dump after the
    initial OCILogon2() call had returned the error code.
    Here is a stack trace of the exact errors (I wrote a smaller test
    application which is stripped down and not multi-threaded and I
    can duplicate this error at will):
    --- begin stack trace ---
    libclntsh.so.9.0`kpucpgetconn+0x27c(d7408, 54388, ffbef0f4, feef9804, 18, 0)
    libclntsh.so.9.0`kpucpfnd+0x50(d7408, ffbef1a8, ffbef18c, ffbef0f4, 18, 0)
    libclntsh.so.9.0`kpcpmap+0x94(4e28c, d7408, ffbef1a8, ffbef18c, ffbef1ac, 0)
    libclntsh.so.9.0`kpuauthxa+0x720(1, 5449c, 5cea4, 1, 0, 0)
    libclntsh.so.9.0`kpuauth+0x44(5d028, 5449c, 5cea4, 1, 0, fefcdb64)
    libclntsh.so.9.0`kpulon2+0x37c(200, 1d, 54358, 7, 15e0, fefcdb64)
    libclntsh.so.9.0`OCILogon2+0x130(200, 7, ffbef65c, 11cc8, 6, 11cd0)
    --- end stack trace ---
    What I'm curious about is why the OCILogon2() API does not return
    an error code of some sorts whenever the connection is obviously
    unavailable.
    I'm not extremely knowledgeable about the OCI APIs, so is there
    perhaps a way to verify the connection is active before attempting
    a login call? (Whether that be OCILogon2() or OCIServerAttach(), etc.)
    A 'ping' of sorts just to be sure? (Not that this would solve the
    problem completely as the connection could be severed between the
    ping and the login attempt.)
    For other reasons, I already have a 'flag' which can be tripped to
    tell the threads to not attempt Oracle queries (namely if the
    environment initialization upfront failed). I could trip this flag upon
    receiving an Oracle error like this, but that will not be a complete
    solution to the problem due to timing issues -- another thread could be
    attempting to login at the same time another thread is doing so
    and before the flag can be set or checked, thus the second attempt is
    going to cause a core dump, no exceptions. Or if all of the connection
    pool links are currently busy, a thread could check the flag and see
    that it is clear before attempting to login, so OCILogon2() is called
    and the thread is now waiting for a connection to open in the pool;
    the connection dies, one of the other threads throws ORA-03113
    before leaving the pool and setting the flag, but now this other
    "waiting" thread (who already checked the flag before trying to login)
    grabs the open pool spot and immediately tries to complete its
    OCILogon2() call. Core dump.
    The ideal solution is, obviously, for the API to not core dump and
    simply return a proper error code.
    If anyone has any suggestions, I would greatly appreciate them.
    If there is a workaround for this, such as being able to detect ahead
    of time that the connection is down and then trying to reconnect, I'd
    be interested in hearing about ways to do that as well.

    What if you don't have a support contract with Oracle, can you still contact them in a case like this (where I'm not asking someone to show me how to do something, but instead where it is clearly an issue with their product)?
    Thanks for your reply.

  • Weblogic 6.1 sp5 core dump by OCI driver

    I have encountered a core dump problem on weblogic server 6.1 SP5 the error message
    as below, I am using weblogic oci driver for oracle "libweblogicoci37.so" , anyone
    can help?
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : 4 occurred at PC=0x242795c
    Function name=(N/A)
    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.

    Galen Boyer wrote:
    On Sun, 28 Mar 2004, [email protected] wrote:
    Galen Boyer wrote:
    On Sat, 27 Mar 2004, [email protected] wrote:
    One way to get a substantial boost in reliability is to switch
    to the latest appropriate Oracle thin driver.But then you can suffer performance losses.Actually, the latest oracle thin drivers are very fast. The 10g
    driver in particular. Well, we are on 9i here and we have lots of CLOB and BLOB
    operations. Understood. The latest should work. (How comfortable does that make you ;) )
    It is a sad choice we used to have to make between
    faster-but-buggy homicidal old OCI code (wherein a bug in one
    module can cause a segfault in an innocent unrelated module's
    execution, and bring down a whole JVM) and the reliability of
    Java. Fortunately, the future is at hand. The future is at hand? I do believe you are starting to sound a
    bit like an evangelist. :-)Yep. Back in '96 when we wrote and marketed all the first JDBC drivers
    for MS SQLServer, Oracle, Informix and Sybase, we did it solely
    so enable our application server to be able to do real work. We were all
    absolutely sure the driver market would dry up in 6 months as all the
    DBMS vendors made excellent free type-4 drivers. We were over-optimistic.
    Sybase's driver still requires you to install non-standard tables and
    procedures in the DBMS. Oracle drivers are sloutching toward sufficiency,
    but their first GA driver had a hard-wired value of READ_UNCOMMITTED
    for getTransactionIsolation, and if you tried setTransactionIsolation
    of either READ_COMMITTED or SERIALIZABLE, the driver would throw an
    exception! We actually had a weblogic workaround to intercept this
    jdbc call and send the "ALTER SESSION " to do what the customer wanted!
    At the same time we had a major struggle to get Oracle to admit that
    in spite of their documentation, OCI was not threadsafe (killing our
    OCI-based driver in weblogic applications) until 7.1.4 on solaris
    and NT, and 8.0.5 on other platforms. Did you know they had separate
    codelines for OCI on each platform? For a while each platform's OCI
    had a different hard-wired limit of the number of simultaneous connections
    on client could have? For a while that limited what our application server
    could do. OCI was written for simple teller-like client applications.
    The new thin drivers take on more of the possible client-side
    processing, and can do RAC failover etc. JoeOh well. I for one am a bit skeptical that Oracle is going to
    fix java driver bugs before OCI bugs and I don't have any reason
    to commit to any "platform independent" solution like java's thin
    driver. We are completely based on Oracle here and we have a
    J2EE solution for the app just cause we had to choose something.
    If thin is better, than we will go with that.The last highest-level talks I had with Oracle folks they indicated that
    they wanted everyone to go thin. OCI was a headache for them. Their
    OCI code was undocumented and all the original experts had left the company.
    That was in 2000 or so, so it is likely better now. They may well have
    invested a lot of reverse-documentation by now.
    One of the benefits of Java is the reliability. I think you'll
    ultimately be happier with the thin. We do want you successful.
    Joe

  • Pro*c program causing core dump in 11g

    hello every one,
    I am trying to debug a pro*c program which is resulting in a core dump. It used to work fine in with Oracle 10g precompiler but is causing a core dump with 11g. When I run dbx here is what I get.
    dbx wreg309
    Type 'help' for help.
    [using memory image in core]
    reading symbolic information ...
    Segmentation fault in u_fsetcodepage_3_8 at 0x9000000014f4f70 ($t1)
    0x9000000014f4f70 (u_fsetcodepage_3_8+0x68) f87f0010 std r3,0x10(r31)
    Any ideas what this means ? Thanks.

    Hi,
    I came across your problem on the Oracle Discussions Forum from back on June of 2009.
    I am working with a pro*c program, in Banner 8. I getting the same message from a core dump,, that you got. I was hoping
    you might have written down what you did to resolve it.
    My pro*c program is key to running all the SQR code we have. So it's very important. The version of sqr that gets
    linked into it is 32-bit and our environment is 64-bit. Our contract with Oracle for SQR has lapsed (it's a long
    and expensive story and this is probably not the place). My whole migration to Oracle 11 is being held up by this.
    I realize it's been a while since you worked on it but if you could tell me how you resolved your problem, I might be
    able to do the same.
    Thanks,
    Tom Mayne
    North Shore Community College
    Danvers MA
    [email protected]
    cell 978 423 6867

  • OCI connect error reported to cause core dump

    I use OCI in my developped library. Other developers use my library for their development purposes. Last night, the oracle server went down for patching, and a user reported a core dump that I recognized it is comming from my OCI section of library.
    I do OCI initialization, select, execute a query, and cleanup.
    Has there been any reports as for the case, when a connection is initialized, and the server goes down after successful initialization but before calls to execute a query or commit?
    Any comment???
    I have the error message below, and replace prepriotory info with xxxxxxx.
    thanks,
    --M
    Fatal NI connect error 12541, connecting to:
    (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxxx)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=xxxxxx)(CID=(PROGRAM=xxxxxx@fashing)(HOST=xxxxxx)(USER=xxxxx))))
    VERSION INFORMATION:
    TNS for Solaris: Version 10.1.0.4.0 - Production
    TCP/IP NT Protocol Adapter for Solaris: Version 10.1.0.4.0 - Production
    Time: 15-FEB-2007 15:49:09
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12541
    TNS-12541: TNS:no listener
    ns secondary err code: 12560
    nt main err code: 511
    TNS-00511: No listener

    We have seen core dumps in system calls earlier and have tried to debug them. We did not have the exact same stack as you but the core used to show up a stack in _malloc.
    As it turned out that we had out of bound array reads (used purify to detect this) and which resulted in this dump. So the stack shown in this case could be totally misleading and the real cause could be somewhere else.
    Hope this helps.

Maybe you are looking for

  • Automatic creation of Purchase order not possible for 103 mvt type

    Hi, If i could configure "create p.o automatically", while doing G.R for mvt type 101, why cannot i do the same with 103 mvt type. I checked the checkbox "create p.o automatically" for movement type 103 and tried to do G.R for others using Mvt type 1

  • Old, deleted e-mails in mail app rise from the dead...

    I decided to change from hotmail to gmail because I thought it would sync and work well with the Mail app. - Guess not. Over the past week I've discovered several problems. Firstly, any incoming e-mails are in two different folders. They are under "I

  • SQL Server Configuration Manager

    Hello, I have a SQL 2008 SP3 install on Server 2012.  It is clustered active/active.  When opening SQL Server Configuration Manager > SQL Server Services, I receive the following message: The server threw an exception [0x80010105] I have tried restar

  • Setting up an ipad for someone who doesn't have a computer

    I want to get my parents an ipad but they don't have a computer.  I'm happy to use my computer but I don't want to mess up my own itunes account.  Any pointers on how to do this would be appreciated.  They are both in the late 80s so making them tech

  • Business Content Source System Assignment???

    Hi Gurus, i am installing Business content and after going thru few posts in this Forums i have been hearing about Source system assignment in the Business content screen. but when ever i installed i never really used this option and we have only one