| Bug #59059 | Memory leak with 5.01.08.00 - simple test case | ||
|---|---|---|---|
| Submitted: | 20 Dec 2010 15:20 | Modified: | 12 Jun 2012 11:20 |
| Reporter: | Eric Masson | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S2 (Serious) |
| Version: | 5.01.08.00 | OS: | Any |
| Assigned to: | Bogdan Degtyariov | CPU Architecture: | Any |
[20 Dec 2010 19:33]
MySQL Verification Team
I couldn't the with the test case provided my memory usage displayed by task manager on Vista keep the same as 1824 Kb.
[20 Dec 2010 20:59]
Eric Masson
It is important to change the DSN, UID and PWD to something that actually works on your system. It appears that if invalid data is specified no leak appears. I'm running on Win XP - each time the program pauses, I'm losing approximately 50K.
[21 Dec 2010 10:28]
Bogdan Degtyariov
Verified with MyODBC driver 5.1.8. Even bringing SQLAllocHandle for HENV did not eliminate the leak.
[21 Dec 2010 10:42]
Bogdan Degtyariov
Looks like a simple loop that consists of SQLDriverConnect/SQLDisconnect produces memory leak. version 5.1.7 is affected too. 5.1.6 works ok.
[11 Jan 2011 5:41]
Bogdan Degtyariov
Very hard bug, because odbc32.dll is calling SQLGetInfo() before disconnecting (SQLDisconnect()). This call is not logged into the ODBC trace and this finding was quite a surprise. The actual memory leak happens in SQLGetInfo(). Trying to find more details
[13 Jan 2011 11:53]
Bogdan Degtyariov
The latest test results show that the memory leak is triggered by incorrect result returned by SQLGetDiacRec function.
[12 Jun 2012 11:20]
Bogdan Degtyariov
Fixed in revision 1037
Description: I have been tracing down a problem which I thought was a memory leak with our code. It turns out there is a memory leak in the MySQL ODBC driver. Here's a very simple test program which will reproduce the problem. Each time the program pauses, you'll notice the memory usage of the program has increased. I have tried this with a SQL Server DSN and there is no leak. I have also found a workaround to at least minimize the amount of memory leaked. If you enable connection pooling for the driver, allocate one environment handle globally and enable pooling within the app I see no leak. How to repeat: Use the following program - make sure you change the DSN, UID and PWD. Also make sure you have the datasource configured. #include <windows.h> #include <sql.h> #include <sqlext.h> #include <stdio.h> #include <time.h> int main(int argc, char *argv[]) { char str[255], conn[255]; sprintf(str,"DSN=database;UID=user;PWD=password;"); time_t tme=time(NULL); while(1){ HENV henv; HDBC hdbc; SHORT len; SQLAllocHandle(SQL_HANDLE_ENV,NULL,&henv); SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0); SQLAllocHandle(SQL_HANDLE_DBC,henv,&hdbc); SQLDriverConnect(hdbc,NULL,(SQLCHAR *)str, (short)strlen(str),(unsigned char *)conn, 255, &len, SQL_DRIVER_NOPROMPT); SQLDisconnect(hdbc); SQLFreeHandle(SQL_HANDLE_DBC,hdbc); SQLFreeHandle(SQL_HANDLE_ENV, henv); if(time(NULL)-tme>5){ Sleep(5000); tme=time(NULL); } } return 0; } Suggested fix: I suspect this may be due to some internal storage of the environment data.