Bug 1215670

Summary:	hashmap mempool used by sd_journal_open() is not released
Product:	[Fedora] Fedora	Reporter:	Tomas Heinrich <theinric>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	23	CC:	johannbg, jsynacek, lnykryn, lpoetter, msekleta, pvrabec, s, systemd-maint, zbyszek
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-10 14:17:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.