Bug 1215670 - hashmap mempool used by sd_journal_open() is not released
Summary: hashmap mempool used by sd_journal_open() is not released
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-27 12:40 UTC by Tomas Heinrich
Modified: 2016-09-20 04:50 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-10 14:17:14 UTC
Type: Bug


Attachments (Terms of Use)

Description Tomas Heinrich 2015-04-27 12:40:42 UTC
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.

Comment 1 Zbigniew Jędrzejewski-Szmek 2015-04-27 13:10:06 UTC
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.

Comment 2 Lennart Poettering 2015-06-17 23:19:40 UTC
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.

Comment 3 Tomas Heinrich 2015-06-18 12:44:53 UTC
(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?

Comment 4 Jan Kurik 2015-07-15 14:14:11 UTC
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

Comment 5 Lennart Poettering 2016-02-10 14:17:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.