#177 Memleak when use mysqlclient_r

[Anonymous]

Andy,

Andy Dustman wrote:

On 3/29/06, Marcus Grando
sbhornia@users.sourceforge.net wrote:

Message body follows:

It's true. I talk with mysql developers (Sergei
Golubchik
serg@mysql.com) and today the uniq method to
eliminate
memleak in
mysqlclient_r is using mysql_thread_close() after
mysql_close().

Look this BUG:
http://bugs.mysql.com/bug.php?id=3D7619

The problem from a Python perspective is, there's
no way to get
mysql_thread_end() called automatically when Python
actually ends a
thread.

If you want to try it. edit
_mysql_ConnectionObject_close() in
_mysql.c and call mysql_thread_end() after closing
the connection.

I do it. Works fine to me, but...

However one problem I can see with this is if you
have multiple
connection objects active in the same thread. Plus
connection objects
can potentially be passed from thread to thread, so
long as only one
thread uses them at a time. (The module is
thread-safe, but are likely
to confuse the wire protocol.) So what happens when
you call
mysql_thread_end() and still have a open connection
somewhere?

I don't know.

For simple use like create threads and each thread
create your
connection and close, call mysql_thread_end() must
work. But complexes
examples like above i don't know.

One idea maybe. Crate one global mutex counter, when
open connection
this counter are incremented and on close
decremented. If this counter
is <=3D 1 then mysql_thread_end().

When you call mysql_real_connect or something he
automaticaly initialize
thread space.

What you think?

Put in a bug and I'll think about it for 1.3.

[Andy Dustman]

Logged In: YES
user_id=71372

Here's one very simple thing you can try: Edit
_mysql_ConnectionObject_dealloc() in mysql.c and simply add
a call to mysql_thread_end(). Install and throw some heavily
multi-threaded app at it and see if it breaks.