MySQL Bugs: #86054: Possible heap corruption with MySQL 5.3.7 ODBC driver (regression from 5.2.7)

Bug #86054	Possible heap corruption with MySQL 5.3.7 ODBC driver (regression from 5.2.7)
Submitted:	24 Apr 2017 11:02	Modified:	5 Dec 2019 9:17
Reporter:	kriti suwalka	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	5.3.7	OS:	Windows (2008 R2 SP1)
Assigned to:		CPU Architecture:	Any
Tags:	crash, Heap corruption, multi threading, Windows 2008

Description:
We are seeing a serious heap corruption issue using latest MySQL ODBC driver 5.3.7 on Windows 2008 R2 SP1 platform. Issue occurs when there are at least two thread used in the ODBC application; each doing some operation with the MySQL database (like one thread doing read and another doing write [or read as well]). If we serialize the methods, then process runs successfully without seeing this issue.

If we use prior MySQL ODBC driver 5.2.7 or below, we don't hit this issue. So this is clear regression in the latest 5.3.7 driver.

How to repeat:
Run the attached sample standalone ODBC program on Windows 20008 R2 SP1 platform.

CPP file reproing the issue, replace xxxx with valid entries

Attachment: MySQL Crash 5.3.7.cpp (text/plain), 14.91 KiB.

Crash Analysis using debug diag tool

Attachment: Crash Analysis.zip (application/x-zip-compressed, text), 247.52 KiB.

Hi Chiranjeevi,

Is there any update on this issue; we've another customer hitting this issue now.

Thanks,
Rahul.

Hi Rahul,

This bug is being processed.
Unfortunately, I cannot provide you with the time estimate for the bug fix. However, if you have a customer contract with Oracle support I strongly encourage you to raise an issue, so this bug would be given the escalated priority.

Thanks.

Thanks Bogdan for the update. While we are checking with out customer on the question you asked; I do sincerely believe that being a regression and a serious product crash, MySQL development team will understand the severity of the issue and provide the fix asap before other customers starts hitting the same.

Oh man, I was loosing 5 days and worked until 4AM at night...

My ASP page was failing all the time with heap corruption... w3wp.exe was failing since I moved to new server 2016...

I had 5.3.6 on the machine, upgraded to 5.3.8, same problem...

Then I finally went to 5.3.2 that I had on the old server... No more w3wp.exe crashes every 3 minutes...

Why does nobody fix this bug. A shame on you!!! It took a life on me to find this!

DO NOT USE ANYTHING NEWER THAN 5.3.4, this version is ok, sice 5.3.6 everything is bad... 2 years and no fix, HELO!

New version of myODBC and still no fix. Are you serious???

Do you plan to fix this verified problem, it maked ODBC unusable!

We were experiencing the same issue, as soon as 2 threads were using the ODBC driver our application crashed. With some digging, we discovered that the actual issue is not with the driver itself but with the Microsoft Visual C++ 2013 Redistributable package which made an application fail if 2 or more threads used the SetLocale method (which is used if you look at the callstack provided in earlier reports of this issue). 
An update for the redistributable and more info is available here: https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-red...

After updating the redistributable, our application stopped crashing and works as expected.

Ok, I can take it, but why is this not happening on the older version of MyODBC? It must have something to do with the code then...

Can confirm Greg Gut's comment.

I was getting w3wp/ntdll crashes every 10 minutes after pointing to a different (remote) db.  

App was a 32 bit asp.net app, resolved:

- install latest odbc driver 5.3.10

- install vcredist_x86.exe  (12.0.40649)

I also seem to be getting heap corruption with the latest ODBC driver  (5.3.10). After analyzing a crash dump I am presented with:

Unhandled exception at 0x776EA899 (ntdll.dll) in xxxxxxx.7356.dmp: 0xC0000374: A heap has been corrupted (parameters: 0x77725910).

The line it errors on is:
kitsQueryRead.Read();
if(kitsQueryRead.GetInt32(0) != 0)

Oddly, it also errored on:

if(kitsQueryRead.HasRows())

I tried both versions to fix the issue if it's something unique I'm doing in .NET.

If I revert to an older MySQL ODBC driver, we get no error.

To add, this is on Windows 10, application is .NET 4.5.2

Sorry... to add again, the application is compiled as 32 bit (limitation from another library) and so the ODBC driver is 32 bit.

It seems with 8.0.12 ODBC driver, this issue is no longer reproducible. Can MySQL support team confirm if we can safely assume this to be fixed?

At this point we could not come up with a reliable scenario to repeat the issue.
Even with the C++ code provided with the problem description it wasn't possible to get the reported behavior even with the ODBC driver 5.3.7.

However, the crash report attached to this report had stack traces containing calls to setlocale() function, which is not thread-safe. We improved the safety of the driver to make sure that the locale changes affect only the calling thread.

Posted by developer:
 
Apologies to everyone that this bug was opened for so long. Multi-thread issues are complex and often it is difficult to pin-point the exact cause of the problem. Especially if we are not able to reproduce the issue locally, as was the case here. It seems that the problem lies in concurrent calls to SetLocale() and this issue we eventually fixed in 8.0. Please use the latest version 8.0 of Con/ODBC and tell us if you still see any such issues.

The MyODBC 5.3.10 is the last version that works for me, after that it doesn't... Not even 8.0.18....