Bug #26932 MYODBC driver seems to have a memory leak in SQLTables function.
Submitted: 7 Mar 2007 19:42 Modified: 28 Jul 2007 18:55
Reporter: Joe Roberts Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S1 (Critical)
Version:3.51.12 OS:Windows (Windows XP)
Assigned to: Jim Winstead CPU Architecture:Any

[7 Mar 2007 19:42] Joe Roberts
Description:
I profiled our code which calls SQLTables using Rational Purify and it always shows huge memory leaks every time that SQLTables is called - it seems that the problem is always reported with SQLTable and then the Kernel leve APIs as the root of the leak.

      

How to repeat:
Just create some tables and call SQLTables as follows:

      ret = _SQLTables(hstmt,
                       NULL, SQL_NTS,
                       NULL,SQL_NTS, 
                       szTableName, SQL_NTS,
                       NULL, SQL_NTS);
[7 Mar 2007 19:43] Joe Roberts
I profiled our code which calls SQLTables using Rational Purify and it always
shows huge memory leaks every time that SQLTables is called - it seems that the
problem is always reported with SQLTables and then the Kernel level APIs as the
root of the leak.
[7 Mar 2007 19:43] Joe Roberts
I profiled our code which calls SQLTables using Rational Purify and it always
shows huge memory leaks every time that SQLTables is called - it seems that the
problem is always reported with SQLTables and then the Kernel level APIs as the
root of the leak.
[8 Mar 2007 2:11] Jim Winstead
Yes, the implementation of SQLTables() is quite creative when it comes to memory.
[28 Jul 2007 18:55] Jim Winstead
This is no longer reproducible with valgrind. It was almost certainly cleaned up when various SQLTables() issues were cleaned up, as well as the handling of "fake" result sets within the driver.