Hide Forgot
Description of problem: I work on a libdnf plugin and I'd like to be able to verify with valgrind that the code is not leaking any memory. Alas, even without any plugin installed, microdnf seems to be leaking memory which makes testing the plugin much harder. Version-Release number of selected component (if applicable): microdnf-3.0.1-1.el8.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. valgrind microdnf install zsh Actual results: # valgrind microdnf install zsh ==15972== Memcheck, a memory error detector ==15972== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==15972== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==15972== Command: microdnf install zsh ==15972== Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Downloading metadata... Package Repository Size Installing: zsh-5.5.1-6.el8.x86_64 beaker-BaseOS 3.0 MB Transaction Summary: Installing: 1 packages Reinstalling: 0 packages Upgrading: 0 packages Removing: 0 packages Downgrading: 0 packages Downloading packages... Running transaction test... Installing: zsh;5.5.1-6.el8;x86_64;beaker-BaseOS ==15972== Syscall param pwrite64(buf) points to uninitialised byte(s) ==15972== at 0x6168517: pwrite (in /usr/lib64/libpthread-2.28.so) ==15972== by 0xC366C14: __os_io (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC352432: ??? (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC3527CB: __memp_bhwrite (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC362936: __memp_sync_int (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC2F8FEE: __db_sync (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC30A937: __db_sync_pp (in /usr/lib64/libdb-5.3.so) ==15972== by 0x88A6EFD: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88B33E9: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88C6BBD: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88DBB49: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88E2613: rpmtsRun (in /usr/lib64/librpm.so.8.1.0) ==15972== Address 0x17038a50 is 2,608 bytes inside a block of size 4,096 alloc'd ==15972== at 0x4C30E8B: malloc (vg_replace_malloc.c:309) ==15972== by 0xC363DF4: __os_malloc (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC3525EF: ??? (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC3527CB: __memp_bhwrite (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC362936: __memp_sync_int (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC2F8FEE: __db_sync (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC30A937: __db_sync_pp (in /usr/lib64/libdb-5.3.so) ==15972== by 0x88A6EFD: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88B33E9: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88C6BBD: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88DBB49: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88E2613: rpmtsRun (in /usr/lib64/librpm.so.8.1.0) ==15972== ==15972== Conditional jump or move depends on uninitialised value(s) ==15972== at 0xC2566C4: __bam_stkrel (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC2470E1: ??? (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC2FD510: __dbc_iput (in /usr/lib64/libdb-5.3.so) ==15972== by 0xC30BF6A: __dbc_put_pp (in /usr/lib64/libdb-5.3.so) ==15972== by 0x88A61D4: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88A817E: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88A8516: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88AF7F2: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88B343F: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88C6BBD: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88DBB49: ??? (in /usr/lib64/librpm.so.8.1.0) ==15972== by 0x88E2613: rpmtsRun (in /usr/lib64/librpm.so.8.1.0) ==15972== Complete. ==15972== ==15972== HEAP SUMMARY: ==15972== in use at exit: 273,863 bytes in 4,301 blocks ==15972== total heap usage: 4,696,352 allocs, 4,692,051 frees, 635,317,086,425 bytes allocated ==15972== ==15972== LEAK SUMMARY: ==15972== definitely lost: 3,009 bytes in 41 blocks ==15972== indirectly lost: 10,872 bytes in 80 blocks ==15972== possibly lost: 32,283 bytes in 372 blocks ==15972== still reachable: 211,571 bytes in 3,680 blocks ==15972== of which reachable via heuristic: ==15972== length64 : 1,224 bytes in 27 blocks ==15972== newarray : 1,744 bytes in 29 blocks ==15972== suppressed: 0 bytes in 0 blocks ==15972== Rerun with --leak-check=full to see details of leaked memory ==15972== ==15972== For counts of detected and suppressed errors, rerun with: -v ==15972== Use --track-origins=yes to see where uninitialised values come from ==15972== ERROR SUMMARY: 27 errors from 2 contexts (suppressed: 0 from 0) Expected results: No "definitely lost" and no "indirectly lost" blocks reported. Additional info:
I created PR in microdnf which fixes some small number of definitely lost bytes: https://github.com/rpm-software-management/microdnf/pull/44 But at least for my local runs of microdnf most of the leaks were caused by rpm plugin "systemd-inhibit", when disabled I saw no additional lost memory (manpage for the plugin describes how to disable it). I looked into the plugin (its fairly simple) and it seems that the blame lies within dbus_bus_get_private call. I couldn't find any problem in the plugin itself. If you encounter any additional leaks please provide the full valgrind output with --leak-check=full.
Thanks for the pointer to rpm-plugin-systemd-inhibit. I was not sure if you planned to track its issues somehow, so I filed bug 1714652 and bug 1714657.
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://access.redhat.com/errata/RHSA-2019:3583