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).

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.

It's possible but unlikely that r61011 fixed this. SocketServer creates
the reference cycles it fixed, but they tended to get cleaned up by
gc.collect(), so it sounds like that wasn't the bug you're seeing here.
I haven't had time yet to check, so I'm mentioning it here so the
possibility doesn't get lost.

I can *not* confirm the leak. I tested using the provided scripts (with
little modifications to log memory usage), using 1000 instead of 20
runs. I am running on Debian Linux and checked the reported Python
2.4.2 and the current trunk (2.6a2). I attached my results for
both. For me it looks like the average memory variations.

I can no longer confirm this bug, either; trying the scripts with the current trunk doesn't seem to leak.  Backing out Jeffrey's r61011 didn't bring the problem back, so I'll just conclude that the problem has gotten fixed along the way somehow.