Tracking memory leaks

[Jonathan M. Gilligan]

Thanks. gc.garbage is empty, but gc.collect with set_debug(DEBUG_STATS)
reports tens of thousands of items in generation 3. Sounds like a
reference-counting bug, but I am only using Numpy 20.1 and calldll, both of
which are widely used, so I would be surprised if there were a
reference-counting bug in one of them.

I instrumented calldll's membuf object and rebuilt it to trace object
creation and destruction and to maintain a linked list of all membuf objects
currently extant, and I find no leaks there. Perhaps the calldll part or
else Numpy, but as I say, too many people use Numpy for me to believe that
it really leaks megabytes per minute from internal flaws (as opposed to me
being too ignorant to use it properly).

"Neil Schemenauer" <nas at python.ca> wrote in message
news:mailman.1005684557.2452.python-list at python.org...
> Jonathan M. Gilligan wrote:
> Make sure there are no objects in the gc.garbage list.  If there are
> then you have objects with __del__ methods that are involved in a
> reference cycle.  If there are not, then you've most likely got a
> reference counting bug somewhere.