On Thu, 24 Apr 2014 17:17:41 +0200, Stefan Krah <ste...@bytereef.org> wrote: > Ethan Furman <et...@stoneleaf.us> wrote: > > >>Any words of wisdom for tracking those leaks? > > Often the easiest way is to compile --with-valgrind and run the test > under Valgrind (obviously). > > In the Valgrind output, search for "definitely lost" and ignore the rest. > > If that does not turn up anything, consider a bug in regrtest.py: > > It happens that certain caches are initialized incrementally in each > repetition of the test, so the reported leaks are spurious. That is > why some caches like small integers are "warmed up" in regrtest.py. > > Perhaps there is some recently added cache that needs attention.
Note that if you do find a "real" leak, I would start with the assumption that any leak is a leak at the python level (eg: a python cache or an possibly-accidentally-persistent data structure) and only move to the C level once I'd ruled out a python source for the "leak". Unless you are dealing with a wholly or primarily C module, of course :) --David _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
