Hide Forgot
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).
https://github.com/systemd/systemd/commit/24f412ca4150b490648ab8de45c6eda5bd697fd8
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)
https://github.com/systemd/systemd/commit/3c747da38ca2f0642b4811812f6e2e2e1449a622
Steps to reproduce ================== 1) Try to reboot nspawn container more than 400 times
https://github.com/systemd/systemd/commit/0810bc568ace619b16e440805e93256730d45541
Steps to reproduce ================== 1) unclear. Probably need to write manual test case which would call sockaddr_pretty with right arguments.
https://github.com/systemd/systemd/commit/f42348ace7feb2311593b8cf6c876856eecf256a
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)
https://github.com/systemd/systemd/commit/4df3277881cffcd3bc9a5238203d6af7e1fd960f
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)
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.
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.
https://github.com/systemd/systemd/commit/bffd87bb1268d90f4261491a6d81814262f62bf6
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)
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.
https://github.com/systemd/systemd/commit/42fbdf45864b46f3eb62a3738b81e687685eb9bd
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)
qa_acking for 7.3
set of these patches merged to staging -> https://github.com/lnykryn/systemd-rhel/pull/18 -> post
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