Bug 1331667
| Summary: | [rhel7.3] Backport memory leak bug fixes | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Michal Sekletar <msekleta> | |
| Component: | systemd | Assignee: | systemd-maint | |
| Status: | CLOSED ERRATA | QA Contact: | Frantisek Sumsal <fsumsal> | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | urgent | |||
| Version: | 7.3 | CC: | bblaskov, chorn, fsumsal, mmatsuya, neil, systemd-maint-list | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | All | |||
| Whiteboard: | ||||
| Fixed In Version: | systemd-219-21.el7 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1368373 1368374 (view as bug list) | Environment: | ||
| Last Closed: | 2016-11-04 00:53:50 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1289485, 1368373, 1368374 | |||
|
Description
Michal Sekletar
2016-04-29 07:52:45 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) Steps to reproduce ================== 1) Try to reboot nspawn container more than 400 times Steps to reproduce ================== 1) unclear. Probably need to write manual test case which would call sockaddr_pretty with right arguments. 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) 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. 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. 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 |