Bug 1857819

Summary: PackageKit leaks large amounts of memory
Product: [Fedora] Fedora Reporter: Joe Thompson <redhat-bugs>
Component: PackageKitAssignee: Richard Hughes <rhughes>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 32CC: bugzilla, gnome-sig, jonathan, klember, mendiebm, rdieter, rhughes, smparrish
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-25 20:46:08 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:

Description Joe Thompson 2020-07-16 15:48:24 UTC 
Description of problem: PackageKit leaks ~1 GB of RAM on my system in a week.


Version-Release number of selected component (if applicable): 1.1.13-3


How reproducible: Always


Steps to Reproduce:
1. Boot a Fedora 32 system with packagekitd enabled.
2. Wait a week

Actual results: packagekitd consumes over 1 GB of RAM.


Expected results: packagekitd consumes a very small amount of memory.


Additional info: Restarting the packagekit service frees up the leaked memory.  valgrind suggests the issue is largely with either liblua, or how PK uses it -- I see a lot of this block in valgrind memory test output:


==2827513==    by 0x160EE656: ??? (in /usr/lib64/liblua-5.3.so)
==2827513==    by 0x160F9530: ??? (in /usr/lib64/liblua-5.3.so)
==2827513==    by 0x160E6936: ??? (in /usr/lib64/liblua-5.3.so)
==2827513==    by 0x160F9F93: ??? (in /usr/lib64/liblua-5.3.so)

The malloc and realloc lines that precede these blocks vary somewhat but are mostly this:

==2827513==    at 0x483A747: malloc (vg_replace_malloc.c:306)
==2827513==    by 0x483CD32: realloc (vg_replace_malloc.c:834)
Comment 1 Chris Murphy 2020-11-25 20:46:08 UTC 

*** This bug has been marked as a duplicate of bug 1896964 ***