Bug #50520 Confirming Memory leak in libmysql.dll
Submitted: 21 Jan 2010 18:56 Modified: 25 Feb 2010 8:51
Reporter: Billiam Volta Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: C API (client library) Severity:S2 (Serious)
Version:6.0.1 OS:Windows
Assigned to: CPU Architecture:Any
Tags: client, Leak, libmysql, libmySQL.dll, library, Memory

[21 Jan 2010 18:56] Billiam Volta
Description:
Confirming I see the same problem as bug http://bugs.mysql.com/bug.php?id=47841 (who saw the same problem as http://bugs.mysql.com/bug.php?id=45002...you have a massive memory leak yo!)

I am using User Mode Dump Heap per this site in order to see the leak
http://support.microsoft.com/kb/268343

When I compare a dump of it after it started and after its run for a while, I get the following entry (which is the only large entry)

//                                                                          
// Each log entry has the following syntax:                                 
//                                                                          
// + BYTES_DELTA (NEW_BYTES - OLD_BYTES) NEW_COUNT allocs BackTrace TRACEID 
// + COUNT_DELTA (NEW_COUNT - OLD_COUNT) BackTrace TRACEID allocations      
//     ... stack trace ...                                                  
//                                                                          
// where:                                                                   
//                                                                          
//     BYTES_DELTA - increase in bytes between before and after log         
//     NEW_BYTES - bytes in after log                                       
//     OLD_BYTES - bytes in before log                                      
//     COUNT_DELTA - increase in allocations between before and after log   
//     NEW_COUNT - number of allocations in after log                       
//     OLD_COUNT - number of allocations in before log                      
//     TRACEID - decimal index of the stack trace in the trace database     
//         (can be used to search for allocation instances in the original  
//         UMDH logs).                                                      
//                                                                          

+  911fe0 ( d2d32f - 41b34f)    cd8 allocs	BackTrace39
+     8d4 (   cd8 -   404)	BackTrace39	allocations

	ntdll!RtlpNtMakeTemporaryKey+000074CE
	ntdll!LdrAlternateResourcesEnabled+00002B05
	ntdll!RtlDosSearchPath_Ustr+00000310
	LIBMYSQL!mysql_fetch_field+000870C8

(the key point being the cd8 allocs...everyone else has something like 1-4, whereas LIBMYSQL just keeps growing and growing)

How to repeat:
I have just a small multi-threaded windows app that accesses a mysql server which is local to the machine. I will try to find more details on how to repeat, but I find it hard to believe you wouldn't see this yourself by just doing a bunch of queries. 

Suggested fix:
I have no idea.
[21 Jan 2010 18:57] Billiam Volta
This guy was seeing the same thing too
http://forums.mysql.com/read.php?45,288710,288710#msg-288710
[25 Jan 2010 8:51] Sveta Smirnova
Thank you for the report.

Bug #45002 is not a bug: test code missed required library call.

Regarding to this case it is hard to say if you experince bug or not. please provide complete test case (C program) showing memory leak.
[26 Feb 2010 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".