Bugs item #1517495, was opened at 2006-07-05 08:47 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517495&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ids van der Molen (idsvandermolen) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak threading or socketserver module Initial Comment: a long running threaded server is not releasing memory, but will keep lots of it for appearantly no reason, causing memory exhaustion. This problem occurs with python 2.4.2 (Suse 10.1 version) and 2.4.3 (customer compiled on RedHat 8.0 and Suse 10.0). The problem does _not_ occur with python 2.2.1 (RedHat 8.0 version). The problem can be reproduced by running multiple concurrent clients sending lots of data (25M)to a threaded server. It looks like the garbage collector does not always release memory used in threads, because the ForkinMixIn and normal variants of the TCPServer do not show this problem (but it may be masked because of seperate process memory space issues). Testing: To reproduce the probme run server code and create multiple client connections by running multiple instances of the client code, using the test run shell script. The server will peak at about 550M, and remain at lower but with every test run increasing amount of memory (and therefore eventually using all available memory). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-09 16:16 Message: Logged In: YES user_id=11375 Confirmed; the sample server does leak on Linux. I couldn't figure out why, though. I doubt it's an interaction between threads and GC, unless there's a refcounting bug in the threading module. gc.garbage doesn't contain anything, so it doesn't look like an __del__ cycle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517495&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
