finding memory leak in edgewall trac 0.11

[Christian Heimes]

Jeroen Ruigrok van der Werven wrote:
> Hi Christian,
> 
> -On [20080119 16:16], Christian Heimes (lists at cheimes.de) wrote:
>> I forgot one important point in my reply. The GC module contains some
>> useful methods for debugging. Check gc.garbage. It should be empty.
> 
> Yeah, we're messing around with that stuff as well as many other ways of
> trying to track issues, but it can really be looking for a needle in a
> haystack to be honest.
> There's so much output that, I guess, make sense only when you're semi-deep
> into the Python internals to even make heads or tails out of it. =\
> And even third-party code is not helping much to reduce the clutter and
> provide insight.

Under normal circumstances gc.garbage should be an empty list. In
general it's a bad sign if gc.garbage contains lots of objects.

I found several potential leaks in trac:

$ find -name \*.py | xargs grep __del__
./trac/versioncontrol/svn_fs.py:    def __del__(self):
./trac/versioncontrol/svn_fs.py:    def __del__(self):
./trac/db/pool.py:    def __del__(self):

$ find -name \*.py | xargs grep frame
./trac/web/main.py:
[...]
./trac/core.py:        frame = sys._getframe(1)
./trac/core.py:        locals_ = frame.f_locals

I recommend that you either replace __del__ with a weak reference
callback or to remove it. Referencing a frame, traceback or f_locals is
going to leak, too. You *must* explicitly del every frame and locals
variable.

Christian