Hunting a memory leak

[Michael Hudson]

Francesc Alted <falted at openlc.org> writes:

> 
> As you can see, for the second loop (first output of TrackRefs), a lot
> of objects appear, but after the third loop (second output of
> TrackRefs), much less appear (only objects of type "int" and
> "type"). Besides, the increment of the total references for the second
> loop is only 7 while for the third loop is 212. Finally, to add even
> more confusion, these numbers are *totally* independent of the number
> of iterations I put in the loops. You see 10 in the code, but you can
> try with 100 (in one or all the loops) and you get exactly the same
> figures.
> 
> I definitely think that I have made a bad implementation of the try:
> code block, but I can't figure out what's going wrong.
> 
> I would appreciate some ideas.

In my experience of hunting these you want to call gc.collect() and
track.update() *inside* the loops.  Other functions you might want to
call are things like sre.purge(), _strptime.clear_cache(),
linecache.clearcache()... there's a seemingly unbounded number of
caches around that can interfere.

Cheers,
mwh

-- 
  A difference which makes no difference is no difference at all.
                        -- William James (I think.  Reference anyone?)