MySQL Bugs: #70662: Memory leak using 5.2.6 ODBC connector

Bug #70662	Memory leak using 5.2.6 ODBC connector
Submitted:	18 Oct 2013 20:57	Modified:	14 Nov 2013 14:05
Reporter:	Ben Macri	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	5.2.6	OS:	Windows
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any

Description:
When updating the contents of a row I get a memory leak using 5.2.6 (and 5.2.5) but not when I use 5.1.13.  This happens whether I am writing string or integers (only ones I tested).  It appears to be about 16k memory increase for each time there is a write to the database.  I did an ODBC trace on both 5.1 and 5.2 and there was no differences in the calls being made.  I am using Microsoft's CDatabase and CRecordset classes.

How to repeat:
I have attached a sample program and the code used to build it.  You can either run the exe or built it locally.  I used VS 2008.

Either create a new database or use an existing one.  Create a table called "odbc_client_test" with a single VARCHAR(50) column called "col0".  Insert a row with whatever data you want.  

Setup a DSN using the 5.2.6 connector and another using the 5.1.13 connector. Run the MySQLError.exe.  The exe will ask for the DSN name, user ID, password, and the number of writes you want.  Here's what it looks like:

Please enter the DSN name:
>mysqltest
Please enter the user ID:
>root
Please enter the password:
>root
Please enter the number of writes you want:
>10

After each write it sleeps for 1.1 seconds so you can see the memory rise.  I recommend using at least a value of 10.  Run it using the 5.2.6 DSN and watch the memory rise.  Run it using the 5.1.13 connector and see the memory stay the same.

Let me know if you have any questions or would like more information.

Hi Ben,

Thank you for your interest in MySQL software.
Also, I would like to say special thanks for the test case, which simplified the bug verification.

Setting the bug status to Verified.

Hi Bogdan,

Great.  Let me know what you find.  I know you guys just released a new version so if you find a work around for this issue please let me know.

Thanks!
-Ben Macri

The patch has been pushed into the Connector/ODBC 5.2 tree revision 1184

Added an entry to the Connector/ODBC 5.2.7 and 5.3.1 changelogs:

"A memory leak occurred when using Connector/ODBC to update the contents of a row."

Hi Guys, I recently moved all our mission critical software to 5.2.5 only to get hit by leaks then 5.2.6 and now hit by leaks again. Is there a work around for this one? I have 7X24X365 software relying on mysql. Is this patch likely to become available soon?

Does version 5.1.13 contain all the leaks in the various versions of 5.2?

Hi Andrew,

I am sorry to hear how much this problem impacts your system.

This particular memory leak can be work-arounded by adding "NO_SSPS=1" to the connection string or by setting the corresponding option in the ODBC Setup dialog:

Details -> Misc -> [x] Prepare statements on the client

Please let me know if this helped.

Answering your question about the version 5.1. The main functional difference between the version 5.1 and 5.2 is using the Server Side Prepared Statements (SSPS) in the version 5.2. Disabling SSPS with NO_SSPS=1 turns the behavior of the version 5.2 into the 5.1, where all SSPS-related code that produces memory leaks is not active. So, you can either migrate to Connector/ODBC 5.1 or use 5.2 with NO_SSPS=1.

In the new source revisions we fixed a few memory leak and crash bugs in both 5.1 and 5.2 branches. So, the new versions of Connector/ODBC drivers 5.1 and 5.2 should bring significant improvements for the stability.

Unfortunately, I cannot tell you the exact date of the new 5.1/5.2 releases and whether any particular patch will go into the particular release because Oracle policy prohibits us from disclosing such information prior to the official release.

Hi Andrew and Bogdan,

Bogdan thank you for working on this issue.  I'm not sure the work around solves this memory leak condition.  I have tried setting it on the DSN and adding it directly to the connection string and both times I still saw the leak.  I know that work around has fixed other memory leaks but this one seems different.  Have you been able to get the sample project to work by using this work around?

Andrew I'm not sure where your leaks are happening but in my case this leak did not occur in 5.1 or 3.5.  If you are experiencing this specific leak then one of those version may help you.

Thanks!
-Ben Macri

Hi Guys, Thanks for the feedback. It makes me feel like something is happening.

With regard to using 5.1 we have rolled back to that connector and are currently testing. Will see what happens.

With regard to 3.5 we went through endless pain to find a version that worked well with our heavily threaded applications without leaks, heap corruption and other unpredictable behavior. We ran for many years on 3.51.08 which we found reasonably stable although a little leaky.

Recently our workload dictated we needed the performance that batch updates offer so went through a rather painful migration from 3.51.08 to 5.25. The text field issue really hit us hard and we had to code A LOT to get around that.

Then to 5.26 to get around leaks. NO_SSPS did not really do it for me either.

The bottom line is that we cant go backwards to 3.5 without spending serious money taking our code base backwards. I cant unscramble the batch update egg at this stage. It is my fault. Knowing all the problems we have had with connectors over the past 10 years I should have run more tests before committing the business to 5.X connectors. I thought things might have improved from the old MySql days but alas this is not the case.

I hope the latest bugs get fixed (installing 5.2.6, the text field one and the latest leak) soon and that there are no more.