Description of problem: Calling sd_journal_close() doesn't seem to release all resources obtained by sd_journal_open() - according to valgrind. Version-Release number of selected component (if applicable): systemd-libs-219-12.fc23.x86_64 Steps to Reproduce: Compile (for example) the code sample from the sd_journal_next() man page. Run it under valgrind. Actual results: ==762== HEAP SUMMARY: ==762== in use at exit: 8,192 bytes in 2 blocks Expected results: The sd_journal_close() man page gives the impression that all resources should be released: $ man sd_journal_close | grep free sd_journal_close() will close the journal context allocated with sd_journal_open() or sd_journal_open_directory() and free its resources.
The memory in question is a mempool used to allocate chunks of memory for hashmaps. This can be mostly ignored, because the memory is not really lost, as it really belong to libsystemd and not to the specific journal object.
Yeah, the mempool is simply an allocation cache. It's not supposed to be freed fully... The memory is not lost, it is reused for subsequent allocations.
(In reply to Lennart Poettering from comment #2) > Yeah, the mempool is simply an allocation cache. It's not supposed to be > freed fully... The memory is not lost, it is reused for subsequent > allocations. Good to know it's not a real problem. Could you then fix the wording in the man page?
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
The memory is released so that it canbe reused for later allocations. This isn't a leak, valgrind will not show this as a leak hence. Using allocation caches is an internal implementation detail of systemd, and is widely used in a lot of other software too (glib, glibc, ...), and I am pretty sure we shouldn#t add documentation for internal implementation details.