Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJan Pazdziora (Red Hat)
2019-04-23 12:06:00 UTC
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.
Comment 2Jan Pazdziora (Red Hat)
2019-05-28 14:17:21 UTC
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