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.
Bug 1702283 - microdnf leaks memory
Summary: microdnf leaks memory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: microdnf
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 8.1
Assignee: amatej
QA Contact: Radek Bíba
URL:
Whiteboard:
Depends On: 1681091
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-23 12:06 UTC by Jan Pazdziora
Modified: 2020-11-14 07:57 UTC (History)
4 users (show)

Fixed In Version: microdnf-3.0.1-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:21:49 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3583 0 None None None 2019-11-05 22:22:01 UTC

Description Jan Pazdziora 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:

Comment 1 amatej 2019-05-28 13:38:39 UTC
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 2 Jan Pazdziora 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.

Comment 19 errata-xmlrpc 2019-11-05 22:21:49 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://access.redhat.com/errata/RHSA-2019:3583


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