I do agree with the assessment, but I'm wondering 1) how you've found it (there might be more hiding), 2) whether address sanitizer runs confirm this, and 3) how we can avoid this in future.

1. Valgrind, ASan, reading the code. Given that the only memory leaked came from inside ireps, it was likely to be a reference counting problem. Then, you just have to read the code following the leaked allocations, and look for anything which might affect the refcounts in unexpected ways.
2. Yes, but don't trust me. I built with make 'CXX=ccache clang++' 'CXXFLAGS=-g -O0 -fsanitize=address -fno-omit-frame-pointer' 'LINKFLAGS=-fsanitize=address' -j6, and then ran the majority of the failed tests from indirect leak in irept::detach #569 (not all, because they're pretty slow in a VM). I'd recommend that we add address sanitizer to the Linux/clang CI so that we can make sure this fixes the issue, and so that further issues are not introduced.
3. Unit tests which are run under ASan would be the process way to avoid this.

Thanks a lot for all the details!

@reuk thanks for fixing this. Once this PR is accepted, please close #569, too.

@mgudemann good catch; @reuk you might want to add "Fixes: #569" to the commit message to automate this step.