[unixODBC-support] SQLConnect failed and memory leak

lizp.net lizp.net at gmail.com
Sat May 29 05:09:21 BST 2010


when I use unixodbc-2.3.0 and libsqora.so.10.1, if SQLConnect return failed,
and the momery will leak. once failed, and the momery will increase about
100Byte.
I used valgrind, and this is some info:

==14955== 4,914 (4,680 direct, 234 indirect) bytes in 117 blocks are
definitely lost in loss record 583 of 595
==14955==    at 0x4A1FF2C: malloc (vg_replace_malloc.c:195)
==14955==    by 0x6500D73: nlpagtkeys (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x6500736: nlpaparse (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x65004FE: nlpardfile (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x64FFE7F: nlpains (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x6503801: nlpacheck_n_load (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x6503486: nlpagap (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x64F15E0: nnfttran (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x64F12C8: nnftrne (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x63EB52F: nnfgrne (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x6516043: nlolgobj (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x63E9359: nnfun2a (in /usr/lib/libclntsh.so.10.1)


==14955== 5,080 (920 direct, 4,160 indirect) bytes in 1 blocks are
definitely lost in loss record 584 of 595
==14955==    at 0x4A1FF2C: malloc (vg_replace_malloc.c:195)
==14955==    by 0x65002AD: nlpains (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x63E7F41: nlstdipi (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x63E5690: nlstdggo (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x63E53CE: nlstdgg (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x6434C0A: nigini1 (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x64357DF: niqname (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x633F25A: kwfnran (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x63000E9: kwfcinit (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x60EB751: kpuatch (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x62641F8: OCIServerAttach (in /usr/lib/libclntsh.so.10.1)
==14955==    by 0x5BAC6E8: bcoOciAttach (in /usr/lib/libsqora.so.10.1)


 ==14955== 32 bytes in 1 blocks are possibly lost in loss record 320 of 595
==14955==    at 0x4A1F250: calloc (vg_replace_malloc.c:418)
==14955==    by 0x5BDCF09: pMEMAlloc (in /usr/lib/libsqora.so.10.1)
==14955==    by 0x5BDCA63: pLstCreate (in /usr/lib/libsqora.so.10.1)
==14955==    by 0x5BE5502: bccSQLAllocEnv (in /usr/lib/libsqora.so.10.1)
==14955==    by 0x5BE5256: SQLAllocHandle (in /usr/lib/libsqora.so.10.1)
==14955==    by 0x4D607CC: __connect_part_one (SQLConnect.c:1325)
==14955==    by 0x4D60DF1: SQLConnect (SQLConnect.c:3886)

I donn't know the memroy leak‘s reason, unixodbc or oralce? How Can I do to
resolve it ? thank u very much!

this is some code:


// allocate connection handle, set timeout
 V_OD_erg = SQLAllocHandle( SQL_HANDLE_DBC, V_OD_Env_, &V_OD_hdbc_ );
 if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))
 {
 INFO_PRT("Error AllocHDB %ld\n",V_OD_erg);
 return false;
 }

 //(SQLPOINTER *)
//  V_OD_erg = SQLSetConnectAttr(V_OD_hdbc_, SQL_LOGIN_TIMEOUT,
(SQLPOINTER)5, 0);
//  if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))
//  {
//   INFO_PRT("Error SQLSetConnectAttr %ld\n",V_OD_erg);
//   SQLFreeHandle( SQL_HANDLE_DBC, V_OD_hdbc_ );
//   return false;
//  }

 // Connect to the data source
 //MysqlODBC //MyPostgres // mysqlitedb
 V_OD_erg = SQLConnect(V_OD_hdbc_, (SQLCHAR*) pszDSN, SQL_NTS,
 (SQLCHAR*) pszUName, SQL_NTS,
 (SQLCHAR*) pszUPasswd, SQL_NTS);
 if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))
 {
 INFO_PRT("Error SQLConnect %ld\n",V_OD_erg);
 SQLGetDiagRec( SQL_HANDLE_DBC, V_OD_hdbc_, 1,
  V_OD_stat, &V_OD_err_, V_OD_msg, 256, &V_OD_mlen );
 INFO_PRT("%s (%ld)\n",V_OD_msg, V_OD_err_);
 SQLFreeHandle( SQL_HANDLE_DBC, V_OD_hdbc_ );
 return false;
 }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20100529/525119fd/attachment.html>


More information about the unixODBC-support mailing list