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 1001957 - some memory leaks in libvirt client
Summary: some memory leaks in libvirt client
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1001536
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-28 08:09 UTC by Ján Tomko
Modified: 2014-06-18 00:54 UTC (History)
7 users (show)

Fixed In Version: libvirt-1.1.1-3.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1001536
Environment:
Last Closed: 2014-06-13 10:26:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ján Tomko 2013-08-28 08:09:03 UTC 
leak (a) from the original bug is already fixed in libvirt-1.1.1-2.el7
all the other leaks are present in libvirt-1.1.1-2.el7
for (b) the leak needs to be reproduced using the VIRSH_LOG_FILE environment variable because of bug 1001628

+++ This bug was initially created as a clone of Bug #1001536 +++

Description of problem:
Found some memory leaks in libvirt client. I'll append more in comments if I find more.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 6.5 Beta
libvirt-0.10.2-23.el6.x86_64
kernel-2.6.32-414.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.398.el6.x86_64

How reproducible:
always

Steps to Reproduce:

(b) virsh with log option cause memory leak.
# valgrind -v --leak-check=full virsh -l log something_cause_log_message

valgrind output:
==30440== 7,700 bytes in 7 blocks are definitely lost in loss record 82 of 90
==30440==    at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==30440==    by 0x4C27B62: realloc (vg_replace_malloc.c:662)
==30440==    by 0x4E884CB: virReallocN (memory.c:160)
==30440==    by 0x4E75666: virBufferGrow (buf.c:129)
==30440==    by 0x4E75BC3: virBufferVasprintf (buf.c:322)
==30440==    by 0x4E75D17: virBufferAsprintf (buf.c:295)
==30440==    by 0x40CB4B: vshOutputLogFile (virsh.c:2349)
==30440==    by 0x40C449: vshError (virsh.c:2174)
==30440==    by 0x40F059: vshCommandParse (virsh.c:1824)
==30440==    by 0x410914: main (virsh.c:2014)
==30440==
==30440== LEAK SUMMARY:
==30440==    definitely lost: 7,700 bytes in 7 blocks

==31698== 2 errors in context 1 of 2:
==31698== Syscall param ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ points to uninitialised byte(s)
==31698==    at 0x6190D4D: ??? (syscall-template.S:82)
==31698==    by 0x38F1815BF7: readline (readline.c:342)
==31698==    by 0x4108C5: main (virsh.c:2610)
==31698==  Address 0x7ff000062 is on thread 1's stack
==31698==  Uninitialised value was created by a stack allocation
==31698==    at 0x409E30: ??? (in /usr/bin/virsh)

(c) run virsh secret-list when no secret exist
# valgrind -v --leak-check=full virsh secret-list

valgrind output:
==11230== 8 bytes in 1 blocks are definitely lost in loss record 4 of 82
==11230==    at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==11230==    by 0x4E8845B: virAllocN (memory.c:128)
==11230==    by 0x4F5B2E2: remoteConnectListAllSecrets (remote_driver.c:3038)
==11230==    by 0x4F0D3F5: virConnectListAllSecrets (libvirt.c:14883)
==11230==    by 0x42DF49: cmdSecretList (virsh-secret.c:348)
==11230==    by 0x40D240: vshCommandRun (virsh.c:1652)
==11230==    by 0x410B4A: main (virsh.c:3093)
==11230==
==11230== LEAK SUMMARY:
==11230==    definitely lost: 8 bytes in 1 blocks

(d) run virsh pool-list with --details option
# valgrind -v --leak-check=full virsh pool-list --details

valgrind output:
==31299== 43 bytes in 1 blocks are definitely lost in loss record 50 of 83
==31299==    at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==31299==    by 0x6BFA137: __vasprintf_chk (vasprintf_chk.c:82)
==31299==    by 0x4E955B3: virVasprintf (stdio2.h:199)
==31299==    by 0x4E95657: virAsprintf (util.c:2029)
==31299==    by 0x42B7A5: cmdPoolList (virsh-pool.c:1129)
==31299==    by 0x40D240: vshCommandRun (virsh.c:1652)
==31299==    by 0x410B4A: main (virsh.c:3093)
==31299==
==31299== LEAK SUMMARY:
==31299==    definitely lost: 43 bytes in 1 blocks

(e) run virsh nodedev-list with invalid --cap option
# valgrind -v --leak-check=full virsh nodedev-list --cap something_invalid

valgrind output:
==4851== 18 bytes in 1 blocks are definitely lost in loss record 20 of 84
==4851==    at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==4851==    by 0x6B790C1: strdup (strdup.c:43)
==4851==    by 0x40EB40: _vshStrdup (virsh.c:129)
==4851==    by 0x40FC68: vshStringToArray (virsh.c:182)
==4851==    by 0x429060: cmdNodeListDevices (virsh-nodedev.c:358)
==4851==    by 0x40D240: vshCommandRun (virsh.c:1652)
==4851==    by 0x410B4A: main (virsh.c:3093)
==4851==
==4851== LEAK SUMMARY:
==4851==    definitely lost: 18 bytes in 1 blocks

--- Additional comment from Jan Tomko on 2013-08-28 09:02:08 CEST ---

Leaks b) to e) are now fixed upstream:
commit 14d5328681448267dfc0812948fa2c6ec4dfa7d4
Author:     Ján Tomko <jtomko>
AuthorDate: 2013-08-27 13:47:57 +0200
Commit:     Ján Tomko <jtomko>
CommitDate: 2013-08-28 08:05:56 +0200

    virsh: free the caps list properly if one of them is invalid
    
    VIR_FREE(caps) is not enough to free an array allocated
    by vshStringToArray.
    
    ==17== 4 bytes in 1 blocks are definitely lost in loss record 4 of 728
    ==17==    by 0x4EFFC44: virStrdup (virstring.c:554)
    ==17==    by 0x128B10: _vshStrdup (virsh.c:125)
    ==17==    by 0x129164: vshStringToArray (virsh.c:218)
    ==17==    by 0x157BB3: cmdNodeListDevices (virsh-nodedev.c:409)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1001536

commit 785ff34bf884a721544ea531c000e8a140e485fa
Author:     Ján Tomko <jtomko>
AuthorDate: 2013-08-27 13:34:09 +0200
Commit:     Ján Tomko <jtomko>
CommitDate: 2013-08-28 08:05:56 +0200

    virsh: free the formatting string when listing pool details
    
    ==23== 41 bytes in 1 blocks are definitely lost in loss record 626 of 727
    ==23==    by 0x4F0099F: virAsprintfInternal (virstring.c:358)
    ==23==    by 0x15D2C9: cmdPoolList (virsh-pool.c:1268)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1001536

commit f733eac058b373822708d3ec889dd80e281fa7e1
Author:     Ján Tomko <jtomko>
AuthorDate: 2013-08-27 13:27:50 +0200
Commit:     Ján Tomko <jtomko>
CommitDate: 2013-08-28 08:05:56 +0200

    virsh: free the list from ListAll APIs even for 0 items
    
    virsh secret-list leak when no secrets are defined:
    
    ==27== 8 bytes in 1 blocks are definitely lost in loss record 6 of 726
    ==27==    by 0x4E941DD: virAllocN (viralloc.c:183)
    ==27==    by 0x5037F1A: remoteConnectListAllSecrets (remote_driver.c:3076)
    ==27==    by 0x5004EC6: virConnectListAllSecrets (libvirt.c:16298)
    ==27==    by 0x15F813: vshSecretListCollect (virsh-secret.c:397)
    ==27==    by 0x15F0E1: cmdSecretList (virsh-secret.c:532)
    
    And so do some other *-list commands.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1001536

commit 66d124b45472addc10d286ca291aa5411fcb381f
Author:     Ján Tomko <jtomko>
AuthorDate: 2013-08-27 13:07:27 +0200
Commit:     Ján Tomko <jtomko>
CommitDate: 2013-08-28 08:05:56 +0200

    virsh: free messages after logging them to a file
    
    The messages were only freed on error.
    
    ==12== 1,100 bytes in 1 blocks are definitely lost in loss record 698 of 729
    ==12==    by 0x4E98C22: virBufferAsprintf (virbuffer.c:294)
    ==12==    by 0x12C950: vshOutputLogFile (virsh.c:2440)
    ==12==    by 0x12880B: vshError (virsh.c:2254)
    ==12==    by 0x131957: vshCommandOptDomainBy (virsh-domain.c:109)
    ==12==    by 0x14253E: cmdStart (virsh-domain.c:3333)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1001536

git describe: v1.1.1-245-g14d5328
Comment 4 Hao Liu 2013-09-02 06:20:10 UTC 
Verified this fix.

Packages:
libvirt-1.1.1-3.el7.x86_64
kernel-3.10.0-14.el7.x86_64
qemu-kvm-1.5.3-2.el7.x86_64

Verify steps:
(b) virsh with log option cause memory leak.
# valgrind -v --leak-check=full virsh -l log something_cause_log_message

(c) run virsh secret-list when no secret exist
# valgrind -v --leak-check=full virsh secret-list

(d) run virsh pool-list with --details option
# valgrind -v --leak-check=full virsh pool-list --details

(e) run virsh nodedev-list with invalid --cap option
# valgrind -v --leak-check=full virsh nodedev-list --cap something_invalid

Results:
no memory leak.
Comment 5 Ludek Smid 2014-06-13 10:26:14 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.