Alexander Mohr <thehes...@gmail.com> added the comment: I realize it doesn't track leaks, it's a tool to help find leaks when used correctly :) This example should be similar to using the compare snapshots mechanism as I start tracking from a stable point (several iterations in after a gc), and then compare to another stable point several iterations later. I have a much more complicated set-up at our company but wanted to keep the example as short as people complain here about large examples.
Further I realize how tracemalloc works, I have a lot of experience in leak hunting from my c++ days, I've even written my own native version of tracemalloc before (it's not hard). The top stat is what bubbles up as the largest leak after a number of runs, that's why the results are so peculiar. I've used tracemalloc before to find https://bugs.python.org/issue29870 in 3.5.2 and there the results made sense, here it makes no sense. To my understanding there should not be any interned strings or other items that would cause this particular callstack to be the top hit of unreleased blocks of memory (leaks). I still don't see any credible reason from why that callstack would be returned. I still believe there's a real bug here, perhaps there's a leak inside the python interpreter implementation it's trying to point out? I think it's worth investigating. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
