Leakage vs Cyclops

[Robin Becker]

In article <mailman.1041746350.26051.python-list at python.org>, Tim Peters
<tim.one at comcast.net> writes
>[Robin Becker]
,......
>
>Beyond what Martin said, Cyclops can only chase pointers in objects of types
>it knows (or has been taught) about.  Objects created by extension modules
>stop it cold (they appear to be sinks), unless Cyclops is taught how to find
>and extract all the references they contain.  I understand you don't think
>extensions are relevant to your problem.
>
......
>
>I wrote Cyclops, but haven't used it since cyclic gc was added.  I don't
>know of any reason it would fail now, as the fundamentals of objects
>pointing to other objects haven't changed, and Cyclops's magic was shallow.
>
>Using 2.2.2 on Windows here, and after installing from
>
......
Well In fact I think I may have been too hasty. I removed one extension,
but another was hanging on the path somewhere else :(. After testing on
another system I see the magnitude of the problem completely reduced by
removing one of the extensions or in fact one particular method. 

Close inspection of that reveals a leak like the bottom of the Atlantic
so I guess that my problem is solved.

This has been interesting for one simple reason, there seems to be no
way to determine the total allocation when I do stupid things like throw
away refs to undecremented PyObjects. 

The python system knows about the memory, but the ordinary user can't
get at the blocks/total allocation for testing purposes. Looking in the
C code it seems there are special allocators for floats and ints, but I
assume that's because these are so frequent it makes sense to block
allocate them.

It seems strange that very few of the malloc implementations make it
easy to find total heap memory. Does the special allocator in 2.3
improve things?
-- 
Robin Becker