On Thu, 24 Apr 2014 17:17:41 +0200, Stefan Krah <stefan at bytereef.org> wrote: > Ethan Furman <ethan at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4