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

Nick Gorham nick at lurcher.org
Fri Apr 16 08:30:47 BST 2010


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


More information about the unixODBC-support mailing list