RE: Memory leak in client-library's mysql_init() and mysql_real_connect() - Mikko Noromaa - com.mysql.lists.bugs

11 messages in com.mysql.lists.bugsRE: Memory leak in client-library's m...

From	Sent On	Attachments
Mikko Noromaa	09 May 2002 10:54
Sinisa Milivojevic	10 May 2002 05:16
Mikko Noromaa	10 May 2002 07:22
Sinisa Milivojevic	10 May 2002 09:08
Mikko Noromaa	10 May 2002 09:51
Sinisa Milivojevic	10 May 2002 09:57
Sinisa Milivojevic	10 May 2002 10:08
Venu	10 May 2002 15:11
Mikko Noromaa	11 May 2002 08:06
Michael Widenius	15 May 2002 01:11
Michael Widenius	15 May 2002 01:45

Subject:	RE: Memory leak in client-library's mysql_init() and mysql_real_connect()
From:	Mikko Noromaa (mik...@nm-sol.com)
Date:	05/10/2002 07:22:41 AM
List:	com.mysql.lists.bugs

Hi,

Thanks for your reply.

The leaks are not OS sockets or Windows handles. The non-freed objects are allocated through the following call-chains:

mysql_init(), libmysql.c line 1008 -> mysql_once_init(), libmysql.c line 1040 -> my_init(), my_init.c line 85 -> my_thread_global_init(), my_thr_init.c line 82 -> my_thread_init(), my_thr_init.c line 121 -> calloc()

And the other one:

mysql_real_connect(), libmysql.c line 1418 -> get_charset(), charset.c line 380 -> init_available_charsets(), charset.c line 191 -> init_dynamic_array(), array.c line 49 -> my_malloc(), safemalloc.c line 144 -> malloc()

In addition, when running the debug build of libmysql, several blocks allocated by DbugMalloc() are not freed. For example in PushState() and code_state().

All these leaks were detected by the simplest possible test program listed in my original post, so they shouldn't be too difficult to reproduce.

-----Original Message----- From: Sinisa Milivojevic [mailto:sin...@mysql.com] Sent: Friday, May 10, 2002 15:17 To: mik...@nm-sol.com Cc: bu...@lists.mysql.com Subject: Re: Memory leak in client-library's mysql_init() and mysql_real_connect()

Mikko Noromaa writes:

Description:

I have created the simplest possible Mysql client in C with the Mysql C API. The program connects to a local Mysql server and immediately disconnects from it. This sequence causes a small memory leak, as reported by Microsoft debug CRT's _CrtDumpMemoryLeaks() function.

The test program is built with Microsoft Visual C++ as a debug version (using "Debug Multithreaded" run-time library). The test program is included at the end of this description.

_CrtDumpMemoryLeaks() checks which objects allocated during the lifetime of a program are not freed at the time _CrtDumpMemoryLeaks() is called. It outputs the following:

374: Detected memory leaks! 374: Dumping objects -> 374: {50} normal block at 0x008F0100, 64 bytes long. 374: Data: <...................> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD 374: {39} normal block at 0x008F02E0, 60 bytes long. 374: Data: <...................> 02 00 00 00 00 00 00 00 5C 00 00 00 B0 7D FA 77 374: Object dump complete.

The first block (50) is allocated by the mysql_init() call and the second block (39) is allocated by the mysql_real_connect() function. I assume they should be freed by the clean-up function mysql_close(), but they aren't.

[skip]

Hi!

Thank you for your bug report.

However, your report does not point out at the pointer that is not released. Can you please try to find out which pointer was not freed(), as we can not deduce that from the above output.

It is also possible that OS socket or WinHandle was not released, but this is truly OS problem.