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.

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

  • Call SQLGLM creates core dump segmentation fault in oracle 9i database

    Hi,
    I am doing call to SQLGLM to get description of error message. This always worked in oracle 9i 32 bit but it does not work with 64 bit installation. I get core dump and segmentation fault.
    Please help.
    Altaf

    wow.. I just upgraded glibc to 2.3.2... and everything works!
    :D

  • 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

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

  • 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

  • Core dump on OCI call

    We are getting the following core dump on an OCI call ....
    fde12fe0 kpucHTDelete (f872ac, f68380, 0, 31, 203d203a, f7c684) + 9c
    fddae464 kpursetstmttext (f872ac, f871c8, 8, fdd9fa84, d49c40,
    fe449a64) + 9c
    fddae61c kpurclientparse (f872ac, f7cc7c, f682e8, 9a, 400000, d49a14) +
    28
    fddae928 kpureq (f77338, f7cc7c, f682e8, 9a, 1, 0) + 150
    fde69efc OCIStmtPrepare (f872ac, f7cc7c, f682e8, 9a, 1, 0) + 7c
    004642b4 arb_internal_process_query (f68138, f68154, 0, 0, ffbfae28,
    1037de2) + 594
    00453178 arb_next_row (f68138, 10d6c58, 1037d88, ffbfaea4, 29, 2e) + 18
    0028d64c ???????? (f61828, 1067d00, ffbfafa8, 0, 0, 80808080)
    0028db68 list_abp_product_types (f61828, 1067d00, ffbfafa8, 1037c10,
    1067d00, 1067d00) + 20
    002e78a0 insert_abp_serv_inst_product (f61828, 103ee18, 1, ffbfb46c,
    fecd29e8, fd9f0240) + 278
    0014feb8 GTEAB_InsertMRC (ffbfbd54, ffbfc2d0, ffbfbda7, ffbfc2d0,
    ffbfbd98, ffbfc2d0) + 33b8
    000d193c run_pieces (e2f820, e33528, e35aa0, ffbfc3d4, e3f8c0, 0) + 1dc
    000d11b0 handle_request (e2f820, 5, e33528, e34e48, 0, 0) + 278
    000ce1a8 process_request (e2f820, 5, e33528, e34e48, fed73700,
    fd9f2a00) + c8
    000cdfd0 main (3, ffbfc9ac, ffbfc9bc, 79a000, fd9f0180, fd9f01c0) +
    568
    000cce08 _start   (0, 0, 0, 0, 0, 0) + 108
    It always seems to happen on the kpucHTDelete call. I have searched the net for kpucHTDelete but found nothing.
    Can someone
    1. describe what kpucHTDelete is supposed to accomplish and why it might fail.
    2. Is there a way to trace / log OCI ?
    3. Any other suggestions to help with this problem.
    Thanks in advance.
    Gary

    Well, it seems to me a bug.
    You can enable tracing using NET 8 Assistant, and from there go to the tracing tab.
    Select the SUPPORT trace level from the following pull down menu located in the Client Information section:
    OFF: Tracing disabled.
    USER: Trace information applicable for users.
    ADMIN: Trace information applicable for database administrators.
    SUPPORT: Trace information applicable for customer support staff.
    Enter a valid directory name in the Trace Directory field in the Client Information section. This directory specification is where trace files are written on either the client or server.
    Enter a valid filename in the Trace File field in the Client Information section. This filename specifies the name of the trace file on the client or server.
    Click on the "unique File Trace Name" checkbox if you want a unique identifier appended to each new trace file created.
    Save your configuration.
    You can check the SQLNET.ORA file found in the net80/admin directory path to verify that tracing is enabled. There is an entry called TRACE_LEVEL_CLIENT=SUPPORT located in that file and entries that indicate the log file location and name that you specified in the Oracle Net8 Assistant.
    regards

  • 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.

  • 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

  • Core dump using OCI HP 32 bit package

    Does any one successfully run OCI application on HP using 32 bit libraries?
    I got core dump at the end of running application, around desctruction part. Following are the statement I got from GDB:
    #0 0xc005db14 in pthread_mutex_destroy+0x18 () from /usr/lib/libpthread.1
    #1 0xc021efd8 in __thread_mutex_free+0x40 () from /usr/lib/libc.2
    #2 0xc0abb4b8 in HPMutexWrapper::~HPMutexWrapper+0x48 () from /usr/lib/libstd_v2.2
    #3 0x613c in std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_C_unlink (this=0x7bff153c) at /opt/aCC/include_std/string:1002
    #4 0xccd0 in ociWrapper::cursor::~cursor (this=0x7bff1538, #free=2) at /vobs/Guru2/IDCE/ociWrapper/ociWrapper.cpp:220
    #5 0x65a8 in main () at /vobs/Guru2/Oracle/HP-UX/sdk/demo/oci_wrapper_insert.cpp:73
    If I build my application in 64 bit using OCI 64 bit package, no problem at all. But I have to make my application work in 32 bit so that I can not simply switch to 64 bit.
    Please give me some help. Thanks.

    I got the problem solved myself. The core dump happens when use OCI 32 bit libraries with STL string. It cores at destroying the STL string.
    Add the option "-mt" to the compile command, the problem will go away.

  • JNI - core dump - internal error on linux after calling Java method

    I'm getting a core dump after calling athe main statric method using JNNI.
    On linux.
    I can get the class id correcttly but when I attempt to call the method it craches with an internal error , anyone know why it would crash instead of just not work.
    if(cls)
        main_methodID = env->GetStaticMethodID(cls, "main", "([Ljava/lang/String;)V");
           printf("Class Found Successfully\n");
      else
        printf ( "cls not found\n");
        return 0;
      if(main_methodID)
              jstring first_str = env->NewStringUTF("The First String");//create string
              jobjectArray args = (jobjectArray)env->NewObjectArray(1,env->FindClass("java/lang/String"), first_str);//new array with 2 elements
                   env->SetObjectArrayElement(args, 2, first_str);//insert the second string into index 1 of the array
              jstring second_str = env->NewStringUTF("The Second String");//create string
              env->SetObjectArrayElement(args, 1, second_str);//insert the second string into index 1 of the array
         env->CallStaticVoidMethod(cls, main_methodID, args);//pass the array to the Java main method
                                  The JAVA method is
      public static void main(String[] args) {
        System.out.println("Main method in Framework");
            Framework framework = new Framework();
                                 

    I see yere points but what I see on linux is it makes it to the constructor of the Java object and somewhere afterwards it bails out, the Java app does work alone. It appears to have problems initializing the JFrame, could there be a problem with the Java inheritance when a JVM is invoked throurgh native invocation??
    Here's some of the Java stuff
    public class Framework extends WindowAdapter {
        public int numWindows = 0;
        private Point lastLocation = null;
        private int maxX = 500;
        private int maxY = 500;
        public Framework() {
            System.out.println("JAVA Framework cnst");//GETTING HERE
            makeNewWindow();
        public void makeNewWindow() {
            System.out.println("JAVA makeWindow"); //GETTING HERE
            JFrame frame = new MyFrame(this); //NOT GETTING HERE!!!!!!!!!
            numWindows++;
            System.out.println("Number of windows: " + numWindows);
            System.out.println("Frame location: " + lastLocation);
            frame.setVisible(true);
            System.out.println("Post Java set frame visible");
        public static void main(String[] args) {
        System.out.println("Main method in Framework");
            Framework framework = new Framework();//GETTING HERE
    class MyFrame extends JFrame {
        protected Dimension defaultSize = new Dimension(200, 200);
        protected Framework framework = null;
        public MyFrame(Framework controller) {
            super("New Frame");
            System.out.println("MyFrame cnst ");//NOT GETTING HERE!!!!!!
            framework = controller;
            setDefaultCloseOperation(DISPOSE_ON_CLOSE);
            addWindowListener(framework);
            JMenu menu = new JMenu("Window");
            menu.setMnemonic(KeyEvent.VK_W);
           setSize(defaultSize);
    }

  • Core Dump when calling DriverManager.getConnection

    I'm very confused and hope someone can help me out with this.
    I'm trying to make a connection to a MS SQL Server 7 and am getting a core dump when getConnection is called. No exception is thrown, just a core dump and locked session. If I run the class from it's main there is absolutly no problem, but when I do a new on the class and call it's member to establish the connection: core dump. The environment is the same in both cases. The calling class did does use a mySql connection, but I tried closing it and setting it to null with the same problem. I'm not sure if the getConnection is stepping on a socket or what it's trying to violate in memory causing the dump. This is running on a SCO Openserver 5.0.5 box (green threads). Why it runs stand-alone and not when called from another class has got me tangled... Thread problem? I've tried several SQL drivers, they all do the same thing.
    Anyway, here's a snippet from the java class:
    try
    {Class.forName(myForName);
    // core dump, next line
    Connection myConn = DriverManager.getConnection(myUrl, myUser, myPass);
    // never get's here
    Statement myStmt = myConn.createStatement();
    catch (Exception e) // modified for this post
    {system.out.println(e.toString());
    Here's the dump printed to the monitor (2>&1)
    SIGSEGV 11* segmentation violation
    si_signo [11]: SIGSEGV 11* segmentation violation
    si_errno [0]: Error 0
    si_code [1]: SEGV_MAPERR [addr: 0x8]
         stackpointer=81adc820
    Full thread dump Classic VM (SCO-JDK-1.2.2-001:2000-Feb-17-03:54, green threads):
    "Thread-0" (TID:0x8074f3c8, sys_thread_t:0x83ae258, state:R) prio=5
         at com.inet.tds.TdsDriver.run(Unknown Source)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "process reaper" (TID:0x807431d0, sys_thread_t:0x82cd980, state:CW) prio=5
         at java.lang.Object.wait(Native Method)
         at java.lang.UNIXProcess.run(Native Method)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "Finalizer" (TID:0x8071f320, sys_thread_t:0x808e478, state:CW) prio=8
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
    "Reference Handler" (TID:0x8071f3b0, sys_thread_t:0x808a2d8, state:CW) prio=10
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java, Compiled Code)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
    "Signal dispatcher" (TID:0x8071f3e0, sys_thread_t:0x80845a8, state:CW) prio=5
    "main" (TID:0x8071f1e0, sys_thread_t:0x804c2d8, state:R) prio=5
         at java.lang.Thread.sleep(Native Method)
         at com.inet.tds.TdsDriver.connect(Unknown Source)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at SLSCorpRpt.printSchedule(SLSCorpRpt.java, Compiled Code)
         at SLSSchedule.runSchedule(SLSSchedule.java, Compiled Code)
         at SLSTextMain.<init>(SLSTextMain.java, Compiled Code)
         at SLSTextMain.main(SLSTextMain.java, Compiled Code)
    Monitor Cache Dump:
    java.lang.Object@807431A8/807C6140: <unowned>
         Waiting to be notified:
         "process reaper" (0x82cd980)
    java.lang.Class@80736EF8/807970A8: owner "main" (0x804c2d8) 2 entries
    <unknown key> (0x80737c21): owner "Thread-0" (0x83ae258) 1 entry
    java.lang.ref.ReferenceQueue$Lock@8071F338/80754D60: <unowned>
         Waiting to be notified:
         "Finalizer" (0x808e478)
    java.lang.ref.Reference$Lock@8071F3C0/80754890: <unowned>
         Waiting to be notified:
         "Reference Handler" (0x808a2d8)
    Registered Monitor Dump:
    PCMap lock: <unowned>
    utf8 hash table: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: owner "Thread-0" (0x83ae258) 1 entry
    Class linking lock: <unowned>
    System class loader lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Monitor cache lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor IO lock: <unowned>
    User signal monitor: <unowned>
         Waiting to be notified:
         "Signal dispatcher" (0x80845a8)
    Child death monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
         Waiting to be notified:
         <unknown thread> (0x804be18)
    Thread queue lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor registry: owner "Thread-0" (0x83ae258) 1 entry
    SIGABRT 6* abort (generated by abort(3) routine)
         stackpointer=81adc820
    Full thread dump Classic VM (SCO-JDK-1.2.2-001:2000-Feb-17-03:54, green threads):
    "Thread-0" (TID:0x8074f3c8, sys_thread_t:0x83ae258, state:R) prio=5
         at com.inet.tds.TdsDriver.run(Unknown Source)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "process reaper" (TID:0x807431d0, sys_thread_t:0x82cd980, state:CW) prio=5
         at java.lang.Object.wait(Native Method)
         at java.lang.UNIXProcess.run(Native Method)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "Finalizer" (TID:0x8071f320, sys_thread_t:0x808e478, state:CW) prio=8
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
    "Reference Handler" (TID:0x8071f3b0, sys_thread_t:0x808a2d8, state:CW) prio=10
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java, Compiled Code)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
    "Signal dispatcher" (TID:0x8071f3e0, sys_thread_t:0x80845a8, state:CW) prio=5
    "main" (TID:0x8071f1e0, sys_thread_t:0x804c2d8, state:R) prio=5
         at java.lang.Thread.sleep(Native Method)
         at com.inet.tds.TdsDriver.connect(Unknown Source)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at SLSCorpRpt.printSchedule(SLSCorpRpt.java, Compiled Code)
         at SLSSchedule.runSchedule(SLSSchedule.java, Compiled Code)
         at SLSTextMain.<init>(SLSTextMain.java, Compiled Code)
         at SLSTextMain.main(SLSTextMain.java, Compiled Code)
    Monitor Cache Dump:
    java.lang.Object@807431A8/807C6140: <unowned>
         Waiting to be notified:
         "process reaper" (0x82cd980)
    java.lang.Class@80736EF8/807970A8: owner "main" (0x804c2d8) 2 entries
    <unknown key> (0x80737c21): owner "Thread-0" (0x83ae258) 1 entry
    java.lang.ref.ReferenceQueue$Lock@8071F338/80754D60: <unowned>
         Waiting to be notified:
         "Finalizer" (0x808e478)
    java.lang.ref.Reference$Lock@8071F3C0/80754890: <unowned>
         Waiting to be notified:
         "Reference Handler" (0x808a2d8)
    Registered Monitor Dump:
    PCMap lock: <unowned>
    utf8 hash table: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: owner "Thread-0" (0x83ae258) 1 entry
    Class linking lock: <unowned>
    System class loader lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Monitor cache lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor IO lock: <unowned>
    User signal monitor: <unowned>
         Waiting to be notified:
         "Signal dispatcher" (0x80845a8)
    Child death monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
         Waiting to be notified:
         <unknown thread> (0x804be18)
    Thread queue lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor registry: owner "Thread-0" (0x83ae258) 1 entry

    I have a similar problem with establishing a connection through JNI. Have you resolved your problem?
    Here's mine.
    In java, I have a class that provides an interface to a mysql database. The java programs that call this interface work fine.
    When I try to call the java interface from C++ through JNI, I get the following output -- some debug statements sprinkled through also. I am assuming that the JVM is missing something at runtime that is there in my JRE. The classpaths match , etc. Exception handling in java and in JNI code are not providing any more detail.. Thanks for comments!!
    Created jvm
    Got KBModel and String classes
    KBModel.java:stest()
    KBModel.java:init(String)
    KBModel.java:init(String) - got Properties file
    Got DBDRIVER class: org.gjt.mm.mysql.Driver
    Object = class org.gjt.mm.mysql.Driver
    init(): DBURLSTRING = jdbc:mysql://sturgeon.xxx.com:3306/<valid db name>
    init(): DBUSER = <valid user>
    init(): DBPASSWORD =<valid password>
    KBModel.java:init(Properties) - Attempting connection
    init(): Drivers available:
    com.mysql.jdbc.Driver
    Driver accepts this URL
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : 11 occurred at PC=0x4053ea09
    Function name=(N/A)
    Library=/lib/i686/libc.so.6
    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.
    Dynamic libraries:
    08048000-0804a000 r-xp 00000000 03:02 279279 /home/kathy/cm/src/Onto/Tools/Annotator/src/test/invokeKB
    0804a000-0804b000 rw-p 00001000 03:02 279279 /home/kathy/cm/src/Onto/Tools/Annotator/src/test/invokeKB
    40000000-40016000 r-xp 00000000 03:02 2093075 /lib/ld-2.2.4.so
    40016000-40017000 rw-p 00015000 03:02 2093075 /lib/ld-2.2.4.so
    40017000-40020000 r-xp 00000000 03:02 1309343 /usr/java/jdk1.3.1_03/jre/lib/i386/native_threads/libhpi.so
    40020000-40021000 rw-p 00008000 03:02 1309343 /usr/java/jdk1.3.1_03/jre/lib/i386/native_threads/libhpi.so
    40031000-40032000 r--p 00000000 03:02 768548 /usr/lib/locale/en_US/LC_IDENTIFICATION
    40033000-40085000 r-xp 00000000 03:02 328384 /usr/lib/libodbc.so.1.0.0
    40085000-40088000 rw-p 00051000 03:02 328384 /usr/lib/libodbc.so.1.0.0
    40088000-400c1000 r-xp 00000000 03:02 327275 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
    400c1000-400c8000 rw-p 00038000 03:02 327275 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
    400ca000-400eb000 r-xp 00000000 03:02 246620 /usr/java/jdk1.3.1_03/jre/lib/i386/libjava.so
    400eb000-400ed000 rw-p 00020000 03:02 246620 /usr/java/jdk1.3.1_03/jre/lib/i386/libjava.so
    400ee000-400ff000 r-xp 00000000 03:02 246629 /usr/java/jdk1.3.1_03/jre/lib/i386/libverify.so
    400ff000-40101000 rw-p 00010000 03:02 246629 /usr/java/jdk1.3.1_03/jre/lib/i386/libverify.so
    40101000-402f1000 r-xp 00000000 03:02 1701922 /usr/java/jdk1.3.1_03/jre/lib/i386/client/libjvm.so
    402f1000-403f1000 rw-p 001ef000 03:02 1701922 /usr/java/jdk1.3.1_03/jre/lib/i386/client/libjvm.so
    40408000-4053c000 r-xp 00000000 03:02 2093084 /lib/libc-2.2.4.so
    4053c000-40542000 rw-p 00133000 03:02 2093084 /lib/libc-2.2.4.so
    40547000-4054a000 r-xp 00000000 03:02 2093088 /lib/libdl-2.2.4.so
    4054a000-4054b000 rw-p 00002000 03:02 2093088 /lib/libdl-2.2.4.so
    4054b000-40558000 r-xp 00000000 03:02 343415 /lib/i686/libpthread-0.9.so
    40558000-40560000 rw-p 0000c000 03:02 343415 /lib/i686/libpthread-0.9.so
    40560000-40582000 r-xp 00000000 03:02 343413 /lib/i686/libm-2.2.4.so
    40582000-40583000 rw-p 00021000 03:02 343413 /lib/i686/libm-2.2.4.so
    40583000-40596000 r-xp 00000000 03:02 2093093 /lib/libnsl-2.2.4.so
    40596000-40597000 rw-p 00012000 03:02 2093093 /lib/libnsl-2.2.4.so
    40599000-405cd000 r-xp 00000000 03:02 328243 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
    405cd000-405d9000 rw-p 00033000 03:02 328243 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
    405dc000-405f0000 r-xp 00000000 03:02 246630 /usr/java/jdk1.3.1_03/jre/lib/i386/libzip.so
    405f0000-405f3000 rw-p 00013000 03:02 246630 /usr/java/jdk1.3.1_03/jre/lib/i386/libzip.so
    405f3000-41327000 r--s 00000000 03:02 1717328 /usr/java/jdk1.3.1_03/jre/lib/rt.jar
    41354000-4164b000 r--s 00000000 03:02 1717321 /usr/java/jdk1.3.1_03/jre/lib/i18n.jar
    4164b000-41661000 r--s 00000000 03:02 1717329 /usr/java/jdk1.3.1_03/jre/lib/sunrsasign.jar
    43709000-4370a000 r--p 00000000 03:02 408823 /usr/lib/locale/en_US/LC_MEASUREMENT
    4370a000-4370b000 r--p 00000000 03:02 2158478 /usr/lib/locale/en_US/LC_TELEPHONE
    4370b000-4370c000 r--p 00000000 03:02 2158480 /usr/lib/locale/en_US/LC_ADDRESS
    4370c000-4370d000 r--p 00000000 03:02 2158479 /usr/lib/locale/en_US/LC_NAME
    4370d000-4370e000 r--p 00000000 03:02 1864168 /usr/lib/locale/en_US/LC_PAPER
    4370e000-4370f000 r--p 00000000 03:02 2174846 /usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
    4370f000-43710000 r--p 00000000 03:02 408822 /usr/lib/locale/en_US/LC_MONETARY
    49d5f000-49d8a000 r--p 00000000 03:02 572342 /usr/lib/locale/en_US/LC_CTYPE
    49d8a000-49d90000 r--p 00000000 03:02 866674 /usr/lib/locale/en_US/LC_COLLATE
    49d90000-49d91000 r--p 00000000 03:02 768549 /usr/lib/locale/en_US/LC_TIME
    49d91000-49d92000 r--p 00000000 03:02 572338 /usr/lib/locale/en_US/LC_NUMERIC
    49d93000-49d9c000 r-xp 00000000 03:02 246627 /usr/java/jdk1.3.1_03/jre/lib/i386/libnet.so
    49d9c000-49d9d000 rw-p 00008000 03:02 246627 /usr/java/jdk1.3.1_03/jre/lib/i386/libnet.so
    49d9d000-49da7000 r-xp 00000000 03:02 2093117 /lib/libnss_nisplus-2.2.4.so
    49da7000-49da8000 rw-p 00009000 03:02 2093117 /lib/libnss_nisplus-2.2.4.so
    49da8000-49dab000 r-xp 00000000 03:02 2093106 /lib/libnss_dns-2.2.4.so
    49dab000-49dac000 rw-p 00002000 03:02 2093106 /lib/libnss_dns-2.2.4.so
    49dad000-49db7000 r-xp 00000000 03:02 2093109 /lib/libnss_files-2.2.4.so
    49db7000-49db8000 rw-p 00009000 03:02 2093109 /lib/libnss_files-2.2.4.so
    4a624000-4a67a000 r--s 00000000 03:02 540401 /usr/java/jdk1.3.1_03/jre/lib/ext/log4j-1.2.6.jar
    4a695000-4a6a3000 r-xp 00000000 03:02 2093122 /lib/libresolv-2.2.4.so
    4a6a3000-4a6a5000 rw-p 0000d000 03:02 2093122 /lib/libresolv-2.2.4.so
    Local Time = Thu Feb 13 13:35:05 2003
    Elapsed Time = 1
    # The exception above was detected in native code outside the VM
    # Java VM: Java HotSpot(TM) Client VM (1.3.1_03-b03 mixed mode)
    # An error report file has been saved as hs_err_pid9210.log.
    # Please refer to the file for further information.
    #

  • Core dump on solaris 8/7 making JNI call.

    Hi,
    I am running solaris 8 and solaris 7 with Java 1.3.1. I have required solaris patches installed on the machine for java 1.3.1.
    From a C program I am making some JNI calls and when I run the program it core dumps at the very first JNI call. C program that make JNI calls are in a .so file.
    Same C code with Java 1.3.1 is running fine on window 2000, AIX 5.1, RedHat Advanced Server 2.1 and SuSE Enterprise Linux 7.
    Any help will be greatly appriciated.
    Thanks

    Hiya,
    Any resolution to this post , we have a native JNI call on a Websphere server running on Solaris 8 .. and same thing happening .. random core dump on the box ..
    No warning , no explanation
    Thanks so much for your help
    (btw . running Sun jvm 1.4.2_13)

  • Compaq Tru64 OCI Core dump at OCIServerAttach

    Hello,
    We get the below core dump on Tru64 and the same code has been working fine on other platforms and Oracle 9i.
    We load connect using a shared object and I have displayed the ldd resolutions below as well..
    Any help appreciated.
    Thanks and Regards
    A
    0x300041a57c4 in sigpnm() "sigpnm.c":122
    0x300041521c8 in sigpnmu() "si.c":240
    0x30004062188 in snlpcgpgnm() "snlpc.c":433
    0x30003fc92a8 in snigpgn() "sniq.c":325
    0x30003f74b98 in niqnamcd() "niqnam.c":244
    0x30003f756f8 in niqname() "niqnam.c":625
    0x30003ccc8b4 in kwfnran() "kwfn.c":189
    0x30003b92c40 in kwfcinit() "kwfc.c":351
    0x30003ac0644 in kpuatch() "kpu.c":1941
    0x30003b1a660 in OCIServerAttach() "oci8.c":722
    0x3000301802c in DG_X_oci_connect(hdbc=0x140072a00, pszServer=0x14010f9a0="oracle10_test", pszUserID=0x14010f9c0="view", pszPassword=0x20000b09720="view", iError=0x20000b09600) "/compaqtrue64/src/lib/oracle10g/../oracle/liboci.c":140
    [export/home2/oracle/10.2.0/lib]$ ldd /export/home2/oracle/i5xs_1/bin/abc_dbora10g.dll
    Main => /export/home2/oracle/i5xs_1/bin/abc_dbora10g.dll
    libclntsh.so.10.1 => /export/home2/oracle/10.2.0/lib/libclntsh.so.10.1
    stc_common.dll => /export/home2/oracle/i5xs_1/bin/abc_common.dll
    libpthread.so => /usr/shlib/libpthread.so
    librt.so => /usr/shlib/librt.so
    libcxx.so => /usr/lib/cmplrs/cxx/libcxx.so
    libexc.so => /usr/shlib/libexc.so
    libc.so => /usr/shlib/libc.so
    libaio_raw.so => /usr/shlib/libaio_raw.so
    libm.so => /usr/shlib/libm.so
    [export/home2/oracle/10.2.0/lib]$ ldd /export/home2/oracle/10.2.0/lib/libclntsh.so.10.1
    Main => /export/home2/oracle/10.2.0/lib/libclntsh.so.10.1
    libexc.so => /usr/shlib/libexc.so
    librt.so => /usr/shlib/librt.so
    libaio_raw.so => /usr/shlib/libaio_raw.so
    libm.so => /usr/shlib/libm.so
    libc.so => /usr/shlib/libc.so
    libpthread.so => /usr/shlib/libpthread.so

    Hello.
    We get the same core dump with the code which works fine on Win32.
    Oracle version is 10.2.0.4. It doesn't depend on how linking is done - with shared libraries or static ones.
    Thread terminated at PC 0x140000018 by signal ILL
    0 0x140000018 in /ppqm/sim/bin/dbld#1 0x3ffbe372f14 in sigpnm() "sigpnm.c":122
    #2 0x3ffbe31eed8 in sigpnmu() "si.c":240
    #3 0x3ffbe22e898 in snlpcgpgnm() "snlpc.c":436
    #4 0x3ffbe195738 in snigpgn() "sniq.c":325
    #5 0x3ffbe134f30 in niqnamcd() "niqnam.c":242
    #6 0x3ffbe135a98 in niqname() "niqnam.c":624
    #7 0x3ffbde96140 in kwfnran() "kwfn.c":185
    #8 0x3ffbdd5a780 in kwfcinit() "kwfc.c":359
    #9 0x3ffbdc864f4 in kpuatch() "kpu.c":1952
    #10 0x3ffbdce1600 in OCIServerAttach() "oci8.c":724
    #11 0x1200d5c10 in oci_loader_init(argc=2, argv=0x11fffbd98, ctlp=0x11fffbea8, psess=0x1400c9268) "../../cdemodp.cpp":182
    Does anybody know or guess what could be a reason and how to solve the problem?
    Thanks in advance.

  • Program crashes in OCI calls

    All,
    The program has set of OCI datatype converion calls from C native to Oracle types. The program crashes in OCI calls specifically in OCINumberFromReal. Below is the stack for the core dump created.
    In call to OCINumberFromReal, when it refences lnxren function, the program crashes with SIGBUS.
    The application in on solaris 10 and Oracle 11g.
    pstack corecore 'core' of 163: quartzCABT -C dom=seirel620 -g 1 -i 127 -u sei4800 -U /home3/seirel620
    f2520b7c _kill    (2, ffbfb374, 1, f4517e90, f43e1c74, ffbfb370) + 8
    f37fcfc0 skgesig_sigactionHandler (1, 9a400, 9bd08, 0, 0, 1) + 25c
    f24656c8 __sighndlr (a, ffbfc898, ffbfc5e0, f37fcd64, 0, 0) + c
    f245f320 call_user_handler (a, ffbfc898, ffbfc5e0, 0, 0, 0) + 234
    f245f4d0 sigacthandler (a, ffbfc898, ffbfc5e0, de79ff, 44, 80ee8) + 64
    --- called from signal handler with signal 10 (SIGBUS) ---
    f341ebcc lnxren (d6694c, 8, de7b42, 0, 0, caee98) + 514
    f36617f4 OCINumberFromReal (f432df90, caed70, 3, de7b42, 13d4, 0) + 5d4
    ff3653f0 __1cPedbCreateCommit6FpnIxlDArray_r1rpc_nMMESSAGE_TYPE__ (d66ab0, ffbfd950, ffbfd7dc, fffffff8, 0, dc5da8) + 948
    ff36cc8c __1cUinvokeExtnlDBService6FipnIxlDArray_r1_nMMESSAGE_TYPE__ (1, d66ab0, ffbfd950, 1, 2, abc14d) + 8c
    002b9b48 __1cUCA_GLOBAL_SUBCA_LINKXCABT4003ModGlblSubCALnk6MpnIxlDArray__nMMESSAGE_TYPE__ (abc152, d64ae0, 13b88, b49cac, f476a08c, 20) + bb0
    002ba774 sh_CABT4003ModG (ffbfdc44, abc1ea, ffbfdc2c, abc1f4, ffbfdbf4, abc209) + 9cc
    Please suggest on how to resolve this.
    Thanks in advance
    satish

    hi Nikeda,
    I replaced the sizeof(double) to DBL_DIG/FLT_DIG constant, now the program doesn't crashes but the conversion is not happening properly.
    The result of any number after conversion is "0".
    Any suggestions, Thanks in advance .. below is the code snippet u asked for ..
    class ABC
    double qty ;
    ott structure
    struct abc_ott
    OCINumber qty ;
    // pro*c code
    EXEC SQL BEGIN DECLARE SECTION ;
    abc_ott * abc_ott_inst ;
    EXEC SQL END DECLARE SECTION ;
    EXEC SQL ALLOCATE :abc_ott_inst ;
    ABC * abc = new ABC ;
    abc->qty = 100.0 ;
    OCINumberFromReal(ociError, &abc->qty, (uword)sizeof(double), &abc_ott_inst->qty ) ;
    // call with DBL_DIG
    OCINumberFromReal(ociError, &abc->qty, DBL_DIG, &abc_ott_inst->qty ) ;
    Edited by: user3894537 on May 20, 2010 8:25 AM
    Edited by: user3894537 on May 20, 2010 8:38 AM

Maybe you are looking for