Bug #1183 MyODBC + ADO/ASP = Memory Leak (setlocale?)
Submitted: 2 Sep 2003 15:37 Modified: 7 Oct 2003 13:46
Reporter: Jeff Veasey Email Updates:
Status: Closed Impact on me:
Category:Connector / ODBC Severity:S1 (Critical)
Version:3.51.06 OS:Windows (Win2000)
Assigned to: Bugs System CPU Architecture:Any

[2 Sep 2003 15:37] Jeff Veasey
Software specs are:
Win2000 w/ SP4 + security hotfixes
MDAC 2.8 (ODBC DLL Version 3.525.1022.0)
MySQL ODBC 3.51 Driver (Version
ODBC Connection Pooling On

Using ADO with VBScript on Active Server Pages, a definite memory leak is seen on the system.  Memory is leaking at approximately 1MB per second on a system at 60 page requests/sec, with each page request averaging a single db connection, four SQL calls, and 30 record fetches.

Examining a core dump of the IIS process, there was a 16-byte pattern replicated numerous times which appeared to be the actual leak itself.  This pattern consisted of seemingly random data with a few readable strings (that appeared to have come from SQL calls), but the following string kept appearing in the leak space:


This is part of a setlocale() string, "English_United States.1252".  On a hunch, the MyODBC setting "Don't Use Setlocale" was turned on, and the memory leak decreased to approximately 0.25MB/sec, still heavy but a bit more controllable.

The ASP code itself is currently not suspect; the exact same code base was used against another database (Sybase ASE) with no memory leak for over three years.  The move to MySQL as a backend database appears to be the culprit.

How to repeat:
The situation described is occurring on two production servers; both have a minimal amount of software installed on them.  The servers are quite busy, each receiving several million hits a day; the leak was unnoticable during testing, but became very clear as soon as the system went live.

Suggested fix:
A string passed to setlocale() appears to be a significant part of the leak, although it is not remaining fully intact in memory.  However, turning off setlocale (reducing, but not eliminating the number of calls to that function), the leak has slowed greatly.  We would be more than happy to provide what information we can about our system in order to track down the cause of this leak.
[22 Sep 2003 0:42] MySQL Verification Team
"We would be more than happy to provide what information we can about
  our system    in order to track down the cause of this leak."

Yes please can you send us a test case with instructions how to run it,
how the method you did used for to measure the leakage memory.

The file (zipped) can be upload at:


please make mention in the file's name about this bug report #.

Thanks in advance.
[6 Oct 2003 3:15] Venu Anuganti
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at

If you can provide more information, feel free to add it
to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.