Memory leak in ConfigObj

John Arbash Meinel john at arbash-meinel.com
Wed Oct 10 23:23:33 BST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not positive if this is anything, but I'm trying to debug a memory leak I'm
running into in a converter.

If I set "gc.set_debug(gc.DEBUG_LEAK)", when gc.collect() runs it will save any
objects that are either part of cycles, or unreachable, etc.

It wasn't clear what the different flags meant. Specifically there is:

DEBUG_COLLECTABLE
    Print information on collectable objects found.

DEBUG_UNCOLLECTABLE
    Print information of uncollectable objects found (objects which are not
reachable but cannot be freed by the collector). These objects will be added to
the garbage list.


What makes an object "collectable" versus "uncollectable". Is Collectable
meaning they are unreferenced, and their reference count is 0, but for whatever
reason they weren't auto cleaned? Or is it they are part of a reference cycle,
and can be cleaned if the cycle is broken.

Anyway, when I run in that form, I start seeing items like:

>>> gc.garbage[-10:]
[{u'log': u'log -r -10..-1 --short --forward', u'commit': u'commit --strict'},
 {'comments': {u'commit': [], u'log': []},  'configspec': {},  'defaults': [],
 'depth': 1,
  'inline_comments': {u'commit': None, u'log': None},
  'main': {u'DEFAULT': {u'email': u'John Arbash Meinel <john at arbash-meinel.com>'},
  u'ALIASES': {u'log': u'log -r -10..-1 --short --forward', u'commit': u'commit
- --strict'}},
  'name': u'ALIASES',  'parent': {u'DEFAULT': {u'email': u'John Arbash Meinel
<john at arbash-meinel.com>'},
  u'ALIASES': {u'log': u'log -r -10..-1 --short --forward', u'commit': u'commit
- --strict'}},
  'scalars': [u'log', u'commit'],  'sections': []},
 [u'log', u'commit'],
 [],
 {u'commit': [], u'log': []},
 {u'commit': None, u'log': None},
 {}, [], [], []]

Which really looks like how ConfigObj would have parsed my
~/.bazaar/bazaar.conf file.


So I'm wondering if when we don't cache the Branch config (branch.get_config()
returns a new object every time) if we aren't leaking memory because ConfigObj
is creating memory cycles.


Andrew- do you have any help for me in understanding the DEBUG_* flags? I'm a
little concerned that my pyrex extension might be getting the refcounts wrong,
and I was hoping to debug that.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDVDlJdeBCYSNAAMRArtTAJ90/QYG6ZfUWMVZ9NG2pooYhCzIlgCeLD1d
sDeo+fpeTixY3d3ow3/p8zQ=
=JE2S
-----END PGP SIGNATURE-----



More information about the bazaar mailing list