From c8995b040f7f030b5038cc06746113bc5b964904 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 13 Oct 2020 16:46:32 -0400 Subject: [PATCH] devblog --- doc/devblog/day_631-632__memory_leak.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/devblog/day_631-632__memory_leak.mdwn diff --git a/doc/devblog/day_631-632__memory_leak.mdwn b/doc/devblog/day_631-632__memory_leak.mdwn new file mode 100644 index 0000000000..2d4fef4d84 --- /dev/null +++ b/doc/devblog/day_631-632__memory_leak.mdwn @@ -0,0 +1,16 @@ +I've spent two days trying to track down a recently introduced memory leak, +or leaks. This was unusually hard because all the profiler could tell +me is the memory is "PINNED", but not what allocated it or anything else +about it. + +I probably should have bisected it, rather than staring at the code and +randomly reimplementing things I thought could be pinning memory. Oops. + +Anyway, I've solved one of them, and the other one, if it's a memory leak +at all, is memory that the profiler does not even show is in use, but that +does appear to be allocated, at least as far as mmap goes. + +-- + +This work was sponsored by Jake Vosloo and Mark Reidenbach +on Patreon.