Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#241 handle leak when connecting in Thread

MySQLdb-1.2
open
Andy Dustman
MySQLdb (285)
5
2012-09-19
2007-11-23
wand_of_wishing
No

windows vista and windows server 2003
python 2.5.1/MySQLdb1.2.2

If you execute attatched file, you can find an handle leakage. Handle of the process increases by 1 every 1 second, even if connection has been closed.

In main thread, closed handle do not cause leakage. but connection that is made in threading.Thread.run()(or other functions called by run()) cause leakage.

Discussion

  • code that causes handle leakage

     
    Attachments
  • Wonlay
    Wonlay
    2008-01-16

    Logged In: YES
    user_id=1136768
    Originator: NO

    I'm running Debian4, python 2.4.4

    The same problem with wand_of_wishing.

    The memory keep growing(Start more than one thread each time, and sleep less time, 0.01 eg.).

    I find some one have got the same problem at:
    http://codetoad.livejournal.com/233177.html

     
  • Logged In: YES
    user_id=71097
    Originator: NO

    This isn't actually a handle leak - it results because mysql_thread_end is not called. Furthermore, I cannot find a reasonable place to insert this call because it is intended to be called prior to pthread_exit, and there is no thread visibility in _mysql.c...

    The only thing I can think of is some form of thread id -> # mysql_init calls. When this count goes to zero mysql_thread_end is called - in a reference counting style.

    Any ideas?

    Valgrind trace-snip produced using debug python 2.5.1, python code is from wonlay's comment, and I terminated the loop after 120 steps. The database was a remote one. Note - line numbers won't correspond to 1.2.2 _mysql.c as I've got a lot of instrumentation.

    ==26180== 1,827,840 bytes in 10,880 blocks are definitely lost in loss record 39 of 39
    ==26180== at 0x4C220BC: calloc (vg_replace_malloc.c:397)
    ==26180== by 0x7CD77E2: my_thread_init (in /usr/lib/libmysqlclient_r.so.15.0.0)
    ==26180== by 0x7CD1DB7: mysql_server_init (in /usr/lib/libmysqlclient_r.so.15.0.0)
    ==26180== by 0x7CF6E2E: mysql_init (in /usr/lib/libmysqlclient_r.so.15.0.0)
    ==26180== by 0x7A73625: _mysql_ConnectionObject_Initialize (_mysql.c:587)
    ==26180== by 0x47C547: wrap_init (typeobject.c:3962)
    ==26180== by 0x514C5B: wrapper_call (descrobject.c:988)
    ==26180== by 0x41E5AD: PyObject_Call (abstract.c:1860)
    ==26180== by 0x4B3FAA: ext_do_call (ceval.c:3844)
    ==26180== by 0x4AE3D4: PyEval_EvalFrameEx (ceval.c:2307)
    ==26180== by 0x4B0A93: PyEval_EvalCodeEx (ceval.c:2831)
    ==26180== by 0x51B03B: function_call (funcobject.c:517)

    This bug should not show itself on win32 due to the fact that the mysql library performs some sort of thread exit cleanup.