Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1331667 - [rhel7.3] Backport memory leak bug fixes
Summary: [rhel7.3] Backport memory leak bug fixes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: All
OS: All
urgent
urgent
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks: 1368373 1368374
TreeView+ depends on / blocked
 
Reported: 2016-04-29 07:52 UTC by Michal Sekletar
Modified: 2018-01-19 05:46 UTC (History)
6 users (show)

Fixed In Version: systemd-219-21.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1368373 1368374 (view as bug list)
Environment:
Last Closed: 2016-11-04 00:53:50 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1361120 None CLOSED Memory leaks found in systemd and its subcomponents 2018-12-27 15:48:37 UTC
Red Hat Product Errata RHBA-2016:2216 normal SHIPPED_LIVE systemd bug fix and enhancement update 2016-11-03 13:24:51 UTC

Internal Links: 1361120

Description Michal Sekletar 2016-04-29 07:52:45 UTC
There has been numerous bug fixes introduced upstream which address memory leaks in systemd itself and other daemons. We should backport fixes which apply to RHEL7 systemd code base. 

This general bug is only a place holder we can reference in commit messages while working on backports. We will update this bug whenever we add some memory leak bugfix to our staging branch with the link to original commit and with steps to reproduce (if available).

Comment 2 Michal Sekletar 2016-04-29 07:59:07 UTC
Steps to reproduce
===================

1) systemctl disable cups
2) Observer similar output in valgrind output
 
==48== 93 (24 direct, 69 indirect) bytes in 1 blocks are definitely lost in loss record 91 of 214
==48==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==48==    by 0x4C2BACB: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==48==    by 0x198A30: unit_file_changes_add (install.c:220)
==48==    by 0x19942F: remove_marked_symlinks_fd (install.c:451)
==48==    by 0x199238: remove_marked_symlinks_fd (install.c:403)
==48==    by 0x1995F6: remove_marked_symlinks (install.c:494)
==48==    by 0x19DA3D: unit_file_disable (install.c:1925)
==48==    by 0x17C302: method_disable_unit_files_generic (dbus-manager.c:1789)
==48==    by 0x17C3A5: method_disable_unit_files (dbus-manager.c:1797)
==48==    by 0x1FAAB4: method_callbacks_run (bus-objects.c:398)
==48==    by 0x1FD323: object_find_and_run (bus-objects.c:1232)
==48==    by 0x1FD97C: bus_process_object (bus-objects.c:1348)

Comment 4 Michal Sekletar 2016-04-29 10:10:44 UTC
Steps to reproduce
==================
1) Try to reboot nspawn container more than 400 times

Comment 6 Michal Sekletar 2016-04-29 10:23:54 UTC
Steps to reproduce
==================
1) unclear. Probably need to write manual test case which would call sockaddr_pretty with right arguments.

Comment 8 Michal Sekletar 2016-04-29 10:29:32 UTC
Steps to reproduce
==================
1) run systemd under valgrind
2) observe output like

==47== 107 bytes in 3 blocks are definitely lost in loss record 105 of 212
==47==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==47==    by 0x5F93FE9: strdup (in /usr/lib64/libc-2.17.so)
==47==    by 0x1C33A5: strv_new_ap (strv.c:163)
==47==    by 0x1C3520: strv_new (strv.c:185)
==47==    by 0x1A03C5: generator_paths (path-lookup.c:232)
==47==    by 0x13B244: manager_run_generators (manager.c:2840)
==47==    by 0x133F40: manager_startup (manager.c:1123)
==47==    by 0x12E020: main (main.c:1668)

Comment 10 Michal Sekletar 2016-04-29 13:00:00 UTC
Steps to reproduce
===================
1) have at least one config file in /etc/modules-load.d/, e.g. 

$ cat /etc/modules-load.d/test.conf
floppy

2) run /usr/lib/systemd/systemd-modules-load under valgrind and observe similar output

==3479== 27 bytes in 1 blocks are definitely lost in loss record 1 of 2
==3479==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3479==    by 0x10F7B4: UnknownInlinedFun (util.h:707)
==3479==    by 0x10F7B4: strjoin (util.c:4909)
==3479==    by 0x10DFFC: files_add.7508.constprop.14 (conf-files.c:72)
==3479==    by 0x10B82E: conf_files_list_strv_internal (conf-files.c:117)
==3479==    by 0x10B82E: conf_files_list_nulstr (conf-files.c:176)
==3479==    by 0x10B82E: main (modules-load.c:268)

Comment 11 Michal Sekletar 2016-04-29 13:29:26 UTC
https://github.com/systemd/systemd/commit/c292c3af38c8c23e183f3e63ef492926cea64bab

I am not sure how to reliably reproduce this one. Currently I can reproduce it because systemctl preset-all is totally borked on our staging branch.

Comment 12 Michal Sekletar 2016-04-29 13:36:01 UTC
https://github.com/systemd/systemd/commit/2f50a2d55bf0a8b5959a6864ae1b39e7e9e0ce08

No real need to test this one. Since it is only leak in test, but hey, its always good to have valgrind clean code in any case.

Comment 14 Michal Sekletar 2016-04-29 14:16:17 UTC
Steps to reproduce
===================

1) Just boot the system and log in. That should create scope unit which should trigger leaking code path.
2) Observe output from valgrind,

==1==    by 0x21ADDD: realloc_multiply (alloc-util.h:67)
==1==    by 0x21BFB0: strv_push (strv.c:448)
==1==    by 0x21C245: strv_consume (strv.c:520)
==1==    by 0x21C33C: strv_extend (strv.c:559)
==1==    by 0x278AD7: unit_write_drop_in (unit.c:3352)
==1==    by 0x278EEB: unit_write_drop_in_private (unit.c:3403)
==1==    by 0x190C21: bus_service_set_transient_property
(dbus-service.c:254)
==1==    by 0x190DBC: bus_service_set_property (dbus-service.c:284)
==1==    by 0x18F00E: bus_unit_set_properties (dbus-unit.c:1226)
==1==    by 0x186F6A: transient_unit_from_message (dbus-manager.c:683)
==1==    by 0x1872B7: method_start_transient_unit (dbus-manager.c:763)

Comment 15 Michal Sekletar 2016-04-29 14:51:42 UTC
https://github.com/systemd/systemd/commit/bcf88fc3f14867f1cabc911c27b661d738281df0

Not exactly sure how to reproduce this one. Maybe by handcrafting some dbus traffic and sending it systemd private dbus socket.

Comment 17 Michal Sekletar 2016-04-29 15:26:32 UTC
Steps to reproduce
==================

1) run valgrind journalctl -u system.slice >/dev/null
2) see valgrind report

==68== 28 bytes in 1 blocks are definitely lost in loss record 1 of 3
==68==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==68==    by 0x173A90: malloc_multiply (util.h:709)
==68==    by 0x175152: strnappend (util.c:980)
==68==    by 0x1751F2: strappend (util.c:992)
==68==    by 0x172727: add_matches_for_unit (logs-show.c:1063)
==68==    by 0x11490D: add_units (journalctl.c:1299)
==68==    by 0x1180E8: main (journalctl.c:2001)

Comment 18 Branislav Blaškovič 2016-05-05 10:27:21 UTC
qa_acking for 7.3

Comment 19 Lukáš Nykrýn 2016-05-05 10:34:54 UTC
set of these patches merged to staging ->
https://github.com/lnykryn/systemd-rhel/pull/18
-> post

Comment 26 errata-xmlrpc 2016-11-04 00:53:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2216.html


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