python memory analysis

[Chris Liechti]

Alexander Hoffmann <alexander.hoffmann at netgenius.de> wrote in
news:mailman.2933.1094487476.5135.python-list at python.org: 

> Hello Jeremy,
> Thanks for your help ! 
> 
> Indeed a first invocation of gc.get_objects already gave me an idea
> about what might go wrong. It seems like the garbage collector does
> not remove objects a and b if a references b even though no one else
> references either a or b. 

the GC cant remove cycles with objects that contain a __del__ method.
non cycles are removed by reference counting anayway.

either dont make circles or don't use __del__, maybe the weakref module can 
be of some use too.

chris


> I will continue my analysis. 
> 
> Thanks,
> Alex
> 
> On Monday 06 September 2004 17:38, Jeremy Bowers wrote:
>> On Mon, 06 Sep 2004 16:51:09 +0200, Alexander Hoffmann wrote:
>> > You probably mean to utilize gc.get_objects and build some kind of
>> > statics upon it, don't you ?
>> > Ok, so this means there is indeed no tool which will help me with
>> > that ? 
>> > :-(
>> >
>> > -alex
>>
>> So far, every time I've had a memory leak in Python, simply running
>> the process until it leaks for a while, then looking at
>> gc.get_objects(), has made it immediately clear what was being
>> leaked. (Regretfully, I have never been able to isolate a test case
>> for any of these leaks.) You usually see a bajillion instances of
>> some class and that has always been enough of a clue.
>>
>> Due to how Python works, I'm not sure it is even possible to create a
>> tool that does any better than that. It is meaningful to talk about a
>> C function that "leaks memory" by allocating and never deallocating,
>> but it is much trickier to assign "blame" in Python in a way that
>> could ever have meaning to a tool. If the object is left lying around
>> it is already because the computer believes somebody has a reference
>> to it; how is the computer to "know" this reference isn't "real"?
>> (Assuming no bugs in Python of course, but even so you're left with
>> the same problem.) 
> 
> 



-- 
Chris <cliechti at gmx.net>