MySQL Bugs: #67137: ODBC Connector 5.2.2 Causing Memory Leaks

Bug #67137	ODBC Connector 5.2.2 Causing Memory Leaks
Submitted:	8 Oct 2012 20:57	Modified:	15 Nov 2012 14:17
Reporter:	Aaron Hall	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	Connector / ODBC	Severity:	S1 (Critical)
Version:	5.2.2	OS:	Any
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any

Description:
I am using labview to write data to a MYSQL database. I was using ODBC Conenctor 5.1 on one computer and 5.2 on another. I noticed that the ODBC Conenctor version 5.2 has a memory leak where the memory usage for the mysqld.exe process with expand till the system crashes. The computer in question is running xp sp3 and MYSQL Server 5.5.25. I changed the data source driver to ODBC Connector 5.1 and there was no memory leak and everything worked fine. 

How to repeat:
Windows XP SP3
Connector/ODBC 5.2.2
MySQL Server 5.2.28

Insert Approximately 100 columns of half INT and half FLOAT at an average rate of a row per second to one table. Watch mysqld.exe in Windows Task Manager memory usage.

Suggested fix:
Do whatever you are doing in 5.1.

Hi Aaron,

Thanks for reporting the problem in MySQL software.
However, I see a few inconsistent things in the details you provided:

 - the version of MySQL server 5.2.28, we do not have such version.
   Did you want to put 5.5.28 or 5.1.28?

 - mysqld.exe is the server process and it is not treating ODBC connections
   in any special way, so the problem would be repeatable from mysql command
   line as well as from any other client.

How many records does it have to insert to cause the crash?

The rate of one record per second does not look feasible to me... 
The current systems have many gigabytes of RAM, so we would need to wait
for many months till it gets all used.

I am also seeing a memory leak with the 5.2.2.0 ODBC 32 bit driver for Windows that I downloaded from mysql.org and installed yesterday. I am doing a query on a field using the like operator: select rid from item_table where path like ?

I bind a parameter that looks like 'thepath%'

P.S. The memory leak does not happen with the 5.1.11.0 driver.

If the memory leak is the case it should be shown in any other process but mysqld. However, I can confirm that the memory leak does exist in Connector/ODBC driver 5.2 and we already have another reported bug for it.

I am marking this report as a duplicate to the bug#67340.
You can monitor the bug fixing progress there as it has all the relevant info and the C test case, which repeats the problem.

I never caught the original reply to my post. I will answer what I can.

"- the version of MySQL server 5.2.28, we do not have such version.
   Did you want to put 5.5.28 or 5.1.28?"

Yes I meant MySQL Server 5.5.28.

" - mysqld.exe is the server process and it is not treating ODBC connections
   in any special way, so the problem would be repeatable from mysql command
   line as well as from any other client."

I will rephrase, "When Connector/ODBC 5.2.2 is installed, the process mysqld.exe has a memory leak when performing inserts to the database.

"How many records does it have to insert to cause the crash?

The rate of one record per second does not look feasible to me... 
The current systems have many gigabytes of RAM, so we would need to wait
for many months till it gets all used."

I am using a Labview VI from labview database connectivity toolkit to perform the inserts. The exact mysql statements are transparent and I don't have the time right now to log and figure them out but I assume one insert is performed to add a single record to a table with 100 columns of data. So one record per second was causing the system to crash within several days. I don't remember all the details, but I recall that the memory usage in task manager was showing over a gigabyte at some point.

Rolling back the ODBC Connector resolved the issue.

Thanks, Bogdan. That is exactly what is happening. The memory leak is in the client application, and we are also using prepared statements. I'll keep an eye on bug 67340.

As reported by Aaron Hall, I too had the unfortunate experience of using the MySQL 5.2 ODBC Connector and now I too have the same memory leak. This is happening on SQL 2012 Enterprise (64) version. I too use MySQL ODBC 5.1 in production with no problems.
Each time I execute the OpenQuery statement from SQL Server approximately 8k of memory is consumed from my existing physical memory total and is never release until the physical memory and the pagefile.sys is completely maxed out then the server crashes. This happens on stand-alones and failover clusters.  In the case of failover clusters, the process rolls the cluster after the memory is consumed then starts the memory leak again on the node that was roll to.  This behavior continues as long as the simple insert statement executes.

Did you folks test your version rigorously? I'm going to attempt to get 5.1 install and move on because we are trying to transition off of our old environment which Windows 2003 and SQL 2008 R2. We are migrating to Windows 2008 R2 and SQL Server 2012 SP1.  Do you guys have an update for this?