Bug 1001957

Summary: some memory leaks in libvirt client
Product: Red Hat Enterprise Linux 7 Reporter: Ján Tomko <jtomko>
Component: libvirtAssignee: Ján Tomko <jtomko>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: acathrow, dyuan, hliu, jdenemar, jtomko, lsu, mzhan
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-1.1.1-3.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1001536 Environment:
Last Closed: 2014-06-13 10:26:14 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:
Bug Depends On: 1001536    
Bug Blocks:    

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.