Debugging memory leaks

[Dave Angel]

On 06/13/2013 02:07 PM, writeson wrote:
> Dieter,
>
> Thanks for the response, and you're correct, debugging memory leaks is tough! So far I haven't had much luck other than determining I have a leak. I've used objgraph to see that objects are being created that don't seem to get cleaned up. What I can't figure out so far is why, they are local variable objects that "should" get cleaned up when they go out scope.
>

Pure python code shouldn't have any leaks, but instead can have what I 
call stagnation.  That's data that's no longer useful, but the program 
has fooled the system into thinking it should hang onto it.

A leak happens in C code, when all the pointers to a given hunk of 
memory have gone away, and there's no way to access it any longer.

In pure Python, you don't work with pointers, but with references, and 
they are ref-counted.  When the count goes to zero, the object is freed. 
  Periodically a gc sweep happens, which catches those circular 
references which never actually go to zero.


So post a fragment of code that seems to cause the problem, and maybe 
someone can explain why.

1) objects with a __del__() method
2) objects that are "cached" by some mechanism
3) objects that collectively represent a lot of data
4) objects that are exposed to buggy C code


-- 
DaveA