Why does this leak memory?

[Steve]

When I run this program:

import configparser, sys, gc
def test():
config=configparser.ConfigParser()
#del(config)
#gc.collect()
test()
sys.stderr.write(sys.version)
gc.set_debug(gc.DEBUG_LEAK|gc.DEBUG_STATS)

It reports:

3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)]gc:
collecting generation 2...
gc: objects in each generation: 453 258 4553
gc: collectable <ConfigParser 026C0050>
gc: collectable <dict 0264DE40>
gc: collectable <OrderedDict 0200FB78>
gc: collectable <_Link 02713300>
gc: collectable <dict 0264D930>
gc: collectable <weakproxy 026BC180>
gc: collectable <OrderedDict 0200FC10>
gc: collectable <_Link 02713350>
gc: collectable <dict 0264D9C0>
gc: collectable <weakproxy 026BC1B0>
gc: collectable <OrderedDict 0200FCA8>
gc: collectable <_Link 02713378>
gc: collectable <dict 0264DC90>
gc: collectable <weakproxy 026BC210>
gc: collectable <SectionProxy 026C0030>
gc: collectable <dict 0264D5D0>
gc: collectable <_Link 02713328>
gc: collectable <dict 0269D8A0>
gc: collectable <weakproxy 026BC150>
gc: done, 19 unreachable, 0 uncollectable, 0.0000s elapsed.

The leaks can be removed by uncommenting both lines shown.

This strikes me as very odd behaviour. Can anyone explain it, or is it a
bug?

Thanks,

S.

 

[John Gordon]

gc: objects in each generation: 453 258 4553
gc: collectable <ConfigParser 026C0050>
gc: collectable <dict 0264DE40>
gc: collectable <OrderedDict 0200FB78>
gc: collectable <_Link 02713300>
gc: collectable <dict 0264D930>
gc: collectable <weakproxy 026BC180>
gc: collectable <OrderedDict 0200FC10>
gc: collectable <_Link 02713350>
gc: collectable <dict 0264D9C0>
gc: collectable <weakproxy 026BC1B0>
gc: collectable <OrderedDict 0200FCA8>
gc: collectable <_Link 02713378>
gc: collectable <dict 0264DC90>
gc: collectable <weakproxy 026BC210>
gc: collectable <SectionProxy 026C0030>
gc: collectable <dict 0264D5D0>
gc: collectable <_Link 02713328>
gc: collectable <dict 0269D8A0>
gc: collectable <weakproxy 026BC150>
gc: done, 19 unreachable, 0 uncollectable, 0.0000s elapsed.

The leaks can be removed by uncommenting both lines shown.

This strikes me as very odd behaviour. Can anyone explain it, or is it a
bug?

I'm unfamiliar with gc output, but just glancing over it I don't see
anything that looks like a leak. It reported that there were 19 objects
which are unreachable and therefore are candidates for being collected.

What makes you think there is a leak?

 

[Steve]

"John Gordon" wrote in message news:[email protected]...

I'm unfamiliar with gc output, but just glancing over it I don't see
anything that looks like a leak. It reported that there were 19 objects
which are unreachable and therefore are candidates for being collected.

What makes you think there is a leak?

Well, I guess I was confused by the terminology. I thought there were leaked
objects _after_ a garbage collection had been run (as it said "collecting
generation 2"). Also, "unreachable" actually appears to mean "unreferenced".
You live n learn...

Cheers.

 

[Ulrich Eckhardt]

Am 08.06.2012 18:02, schrieb Steve:

Well, I guess I was confused by the terminology. I thought there were
leaked objects _after_ a garbage collection had been run (as it said
"collecting generation 2"). Also, "unreachable" actually appears to mean
"unreferenced". You live n learn...

Actually I understand that differently. If you have circular references
between two objects they are both referenced. If neither is referenced
(directly or indirectly) by the current context, they are unreachable
and can be garbage-collected. Being unreferenced implies that it is
unreachable, but not vice-versa.

Uli