Jeroen Ruigrok van der Werven wrote: > Hi Christian, > > -On [20080119 16:16], Christian Heimes ([EMAIL PROTECTED]) 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 -- http://mail.python.org/mailman/listinfo/python-list
