Bug #62977 mysql_close() leaks handles
Submitted: 27 Oct 2011 19:39 Modified: 15 Nov 2011 21:10
Reporter: Harold Clapper Email Updates:
Status: Not a Bug Impact on me:
None 
Category:Connector / C Severity:S3 (Non-critical)
Version:6.0.2 OS:Any
Assigned to: CPU Architecture:Any
Tags: mysql_close handle leak

[27 Oct 2011 19:39] Harold Clapper
Description:
I am using the mysql connecter C library client version 6.0.2. Windows 32bit. I use this mysql client library in a multi-threaded server process. Under some circumstances, the sequence of mysql_init, mysql_real_connect(), mysql_close() is leaking handles. Seems like up to 3 handles at a time.

Not sure exactly the conditions yet that causing the handle leak. But the leaks are consistent in my server process. The number of consumed handles grows significantly to ~27K leaked handles after 10 hours of rigorous use.

I searched google and your bug database but did not find any hits for 6.0.2. There were some hits for early versions back in 2005/2006 but those were reported fixed a while back.

Harold

How to repeat:
mysql_init, mysql_real_connect(), mysql_close() in a multithread process. Still looking for more exact details
[28 Oct 2011 3:10] Valeriy Kravchuk
Looks similar to bug #58662 and/or bug #59114. Please, check.
[28 Oct 2011 13:29] Harold Clapper
Yes, it does look similar to bug #59114 which describes the C++ connector. Good to know the issue exists there also. I had thought to swap out the C connector for the C++ connector, but that does not seem fruitful at this time due to the similar open bug in the C++ connector.

I have more information regarding the C Connector. As an experiment, I used a dedicated thread in my server process that did all the mysql calls. The mysql calls were serialized in the dedicated thread by an Event object such that no mysql calls occurred concurrently and all on the same thread. After 10 hours of rigourous testing - No leaks this way.

But when I make the mysql calls in separate threads in my server process, the leaks occur. It does seem to be about 3 handles per mysql_close(), and it happens consistently resulting in ~27K handle leaks after the same set of tests (10 hours of rigourous testing).
[31 Oct 2011 12:49] Vladislav Vaintroub
There is a handy video tutorial on how to analyze handle leaks with application verifier and windbg on msdn.

http://channel9.msdn.com/Blogs/jeff_dailey/Understanding-handle-leaks-and-how-to-use-htrac...  (embedded video does not seem to work , but Mid quality WMV does)

It does require debug symbols (+source for the best result).

My guess would be that per-thread initialization/termination is missing in the affected program (mysql_thread_init()/end()) or something similar.
[2 Nov 2011 2:36] Harold Clapper
Thanks you, Vladislav. I did not know about mysql_thread_init/end. I will try them and post back with the results. I appreciate you telling me about them. I will also view the tutorial.

Thanks,

Harold
[9 Nov 2011 15:15] Harold Clapper
I added mysql_thread_init/end to my server request handling threads, and as a trial returned one of my mysql accessing code segments to the server request handling threads (which run concurrently). After 10 hours of rigorous testing, no leaks. I am optimistic and will return/move more of my mysql accessing code from the sole dedicated thread to the server request handling threads. I will report back those results also.

Thank you very much. You have been very helpful.
[11 Nov 2011 14:02] Valeriy Kravchuk
So, for now we can assume that this problem was not a result of any bug in MySQL code.
[15 Nov 2011 21:09] Harold Clapper
I have moved more mysql calling code into the individual request handling threads in the server. Again after 10 hours of regression testing, no handle leaks. 

So yes, I think this is not a bug but rather user error.

As time allows, I will be moving many more mysql calling sequences into the individual request handling threads in the server. If leaks occur, I will post back, but I am optimistic that this was all user error.

Thank you very much for your time and help. I am grateful that you showed me the solution to my problem.

Sincerely,

Harold
[15 Nov 2011 21:10] Harold Clapper
I have moved more mysql calling code into the individual request handling threads in the server. Again after 10 hours of regression testing, no handle leaks. 

So yes, I think this is not a bug but rather user error.

As time allows, I will be moving many more mysql calling sequences into the individual request handling threads in the server. If leaks occur, I will post back, but I am optimistic that this was all user error.

Thank you very much for your time and help. I am grateful that you showed me the solution to my problem.

Sincerely,

Harold