I've been getting segfaults running metakit in a persistent python interpreter
(under mod_python, so the interpreter lives for a long time). I just checked
out the metakit head (on the server I'm running 2.4.9.3) and jcw figured out
how to initialize under a python debug build[1] so here is what I can report:
This is a debug python build so when run interactively it outputs the number
of live references after every command.
The tst.py is just
import metakit
import gc
def round1():
def round1():
fname = '/tmp/test.mk'
stor = metakit.storage(fname, 2)
gc.collect() # force cleanup on unreachable objects
return
here is the interactive output, with reference counts.
Python 2.4.1 (#1, Apr 15 2005, 21:18:43)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tst
[23817 refs]
>>> tst.round1()
[23820 refs]
>>> tst.round1()
[23823 refs]
>>> tst.round1()
[23826 refs]
>>> tst.round1()
[23829 refs]
So opening a new storage is leaking three refs per go.
I ran the same test with some python objects I know don't leak (dicts
and lists) as a sanity test and the #refs after each call stayed static,
I'll try and hunt down the leak, but if anyone has any ideas let me know.
NB, I have _not_ tried running CVS head on the live server, but I can't
see any diffs that would fix the refcounts between 2.4.9.3 and HEAD.
-Jack
[1] I reported the bug for building under debug python last year, so
thanks to whoever did the extra work and figured out the fix.
_____________________________________________
Metakit mailing list - [email protected]
http://www.equi4.com/mailman/listinfo/metakit
