[unixODBC-support] Core dump in SQLAllocHandle () for env

[Jade C]

This application has several C++ processes, some are single threaded which
uses one singleton connection. We recently changed one major process to be
multi-threaded to utilize the connection pooling.  The connection pooling is
set generally for all although some processes hold one singleton connection
in memory and reuse it.



Message: 3
> Date: Fri, 16 Apr 2010 08:30:47 +0100
> From: Nick Gorham <nick at lurcher.org>
> Subject: Re: [unixODBC-support] Core dump in SQLAllocHandle () for env
>        handle
> To: Support for the unixODBC project
>        <unixodbc-support at mailman.unixodbc.org>
> Message-ID: <4BC81227.805 at lurcher.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Jade C wrote:
> >
> > Hi,
> >
> > Our application sometimes gets core dump when calling SQLAllocHandle
> > for env handle during the start up of some of the components. We have
> > several C++ components (processes), each of them have some DB
> > initializations during starting up. The core dump does not always
> > happen, and is happening after we added connection pooling recently.
> > Sometimes, all components start up and function well. Sometimes, one
> > of the components has core dump during start up. It can be different
> >  component but the stack trace of the core dump is same:
> > =====
> > (gdb) where
> > #0  0x005a2be1 in __write_nocancel () from /lib/tls/i686/libc.so.6
> > #1  0x0054c82a in _IO_new_file_write () from /lib/tls/i686/libc.so.6
> > #2  0x0054b549 in _IO_new_do_write () from /lib/tls/i686/libc.so.6
> > #3  0x0054ae08 in _IO_new_file_close_it () from /lib/tls/i686/libc.so.6
> > #4  0x00542bf4 in fclose@@GLIBC_2.1 <mailto:fclose@@GLIBC_2.1> () from
> > /lib/tls/i686/libc.so.6
> > #5  0x00f6c0ac in dm_log_write () from /usr/lib/libodbc.so.1
> > #6  0x00f61b15 in SQLTablesW () from /usr/lib/libodbc.so.1
> > #7  0x00f283fe in SQLAllocEnv () from /usr/lib/libodbc.so.1
> > #8  0x00f294d3 in SQLAllocHandle () from /usr/lib/libodbc.so.1
> > #9  0x006d4581 in odbc::DriverManager::_checkInit () at
> > drivermanager.cpp:95
> > =======
> >
> >
> >
> > The  connection pooling is configured for all processes in the
> > odbcinst.ini generally.
> >
> >
> >
> > Following is the source code for odbc::DriverManager::_checkInit () is
> > below:
> >
> >
> >
> > void DriverManager::_checkInit()
> >
> > {
> >
> >   //we lock around this, so two concurrent calls don't result
> >
> >   //in several HENVs being allocated
> >
> >   ODBCXX_LOCKER(DMAccess);
> >
> >
> >
> >   if(henv_==SQL_NULL_HENV) {
> >
> >     SQLRETURN r=
> >
> > #if ODBCVER >= 0x0300
> >
> >       SQLAllocHandle(SQL_HANDLE_ENV,SQL_NULL_HANDLE,&henv_)
> >
> > #else
> >
> >       SQLAllocEnv(&henv_)
> >
> > #endif
> >
> >       ;
> >
> >     if(r!=SQL_SUCCESS && r!=SQL_SUCCESS_WITH_INFO) {
> >
> >       throw SQLException
> >
> >         ("Failed to allocate environment handle");
> >
> >     }
> >
> > #if ODBCVER >= 0x0300
> >
> >     // this should immediately follow an AllocEnv per ODBC3
> >
> >     SQLSetEnvAttr(henv_,
> >
> >                   SQL_ATTR_ODBC_VERSION,
> >
> >                   (SQLPOINTER)SQL_OV_ODBC3,
> >
> >                   SQL_IS_UINTEGER);
> >
> >
> >
> >     SQLSetEnvAttr(henv_,
> >
> >            SQL_ATTR_CONNECTION_POOLING,
> >
> >            (SQLPOINTER)SQL_CP_ONE_PER_DRIVER,
> >
> >            SQL_IS_UINTEGER);
> >
> >
> >
> >
> >
> > #endif
> >
> >     //don't collect warnings
> >
> >     eh_=new ErrorHandler(false);
> >
> >   }
> >
> > }
> >
> >
> >
> > I am not able to reproduce the issue if I turn on SQL trace. Without
> > SQL trace, I can reproduce the problem easily.
> >
> >
> >
> > Any idea and information is highly appreciated.
> >
> > Thanks for your time,
> >
> > Hongling
> >
> >
> Is this multi threaded or single threaded?
>
> Just not sure if its actually got to SQLTables as the trace would indicate.
>
> --
> Nick
>
>
> ------------------------------
>
> _______________________________________________
> unixODBC-support mailing list
> unixODBC-support at mailman.unixodbc.org
> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
>
>
> End of unixODBC-support Digest, Vol 67, Issue 9
> ***********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20100416/315830ea/attachment.html>