Bug 761344

Summary:	memory leak on cmdBlkdeviotune sucessful path
Product:	Red Hat Enterprise Linux 6	Reporter:	Alex Jia <ajia>
Component:	libvirt	Assignee:	Alex Jia <ajia>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.3	CC:	acathrow, dallan, dyuan, mzhan, rwu, veillard, zhpeng
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	libvirt-0.9.9-1.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 06:38:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Alex Jia 2011-12-08 06:09:11 UTC

Description of problem:
Plug memory leak on cmdBlkdeviotune() sucessful path.

Version-Release number of selected component (if applicable):
libvirt-0.9.8-0rc2.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. valgrind -v --leak-check=full virsh blkdeviotune <domain name> <block device>

Note: for instance, you have a guest 'demo' with 'hda' disk, and your guest may be 'shut off' state, then run 'valgrind -v --leak-check=full virsh blkdeviotune demo hda'

  
Actual results:

==12759== 576 bytes in 1 blocks are definitely lost in loss record 18 of 29
==12759==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==12759==    by 0x42134E: _vshCalloc.clone.2 (virsh.c:422)
==12759==    by 0x4217CB: cmdBlkdeviotune (virsh.c:6364)
==12759==    by 0x4136A2: vshCommandRun (virsh.c:16363)
==12759==    by 0x4253FB: main (virsh.c:17865)
==12759==
==12759== LEAK SUMMARY:
==12759==    definitely lost: 576 bytes in 1 blocks
==12759==    indirectly lost: 0 bytes in 0 blocks
==12759==      possibly lost: 0 bytes in 0 blocks
==12759==    still reachable: 126,964 bytes in 1,342 blocks
==12759==         suppressed: 0 bytes in 0 blocks


Expected results:
avoid memory leak.

Additional info:

Comment 1 Alex Jia 2011-12-08 06:12:07 UTC

Patch for upstream:

https://www.redhat.com/archives/libvir-list/2011-December/msg00374.html

Comment 2 Alex Jia 2011-12-09 02:30:04 UTC

Patch has been ACKed and pushed on upstream, but need a devel_ack+.

commit ecf75f83dc5f83b43d24695e1323446137b68770
Author: Alex Jia <ajia>
Date:   Thu Dec 8 14:09:56 2011 +0800

    virsh: plug memory leak on cmdBlkdeviotune() sucessful path
    
    Detected by valgrind. Leak introduced in commit e9bd9a0:
    
    * tools/virsh.c: fix memory leak on cmdBlkdeviotune.
    
    * how to reproduce?
      % valgrind -v --leak-check=full virsh blkdeviotune <domain name> <block device>
    
    * actual valgrind result:
    
    ==12759== 576 bytes in 1 blocks are definitely lost in loss record 18 of 29
    ==12759==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
    ==12759==    by 0x42134E: _vshCalloc.clone.2 (virsh.c:422)
    ==12759==    by 0x4217CB: cmdBlkdeviotune (virsh.c:6364)
    ==12759==    by 0x4136A2: vshCommandRun (virsh.c:16363)
    ==12759==    by 0x4253FB: main (virsh.c:17865)
    ==12759==
    ==12759== LEAK SUMMARY:
    ==12759==    definitely lost: 576 bytes in 1 blocks
    ==12759==    indirectly lost: 0 bytes in 0 blocks
    ==12759==      possibly lost: 0 bytes in 0 blocks
    ==12759==    still reachable: 126,964 bytes in 1,342 blocks
    ==12759==         suppressed: 0 bytes in 0 blocks

Comment 3 zhpeng 2011-12-13 09:57:46 UTC

I can reproduce this with libvirt-0.9.8-1.el6.x86_64

Comment 5 Alex Jia 2012-01-10 03:25:19 UTC

The issue has been fixed with libvirt-0.9.9-1.el6.x86_64 on RHEL6.2(2.6.32-220.el6.x86_64).

# virsh domblklist foo
Target     Source
------------------------------------------------
hda        /var/lib/libvirt/images/foo.img

# valgrind -v --leak-check=full virsh blkdeviotune foo hda
<snip>
==30428== LEAK SUMMARY:
==30428==    definitely lost: 0 bytes in 0 blocks
==30428==    indirectly lost: 0 bytes in 0 blocks
==30428==      possibly lost: 0 bytes in 0 blocks
</snip>

Comment 7 errata-xmlrpc 2012-06-20 06:38:10 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.

http://rhn.redhat.com/errata/RHSA-2012-0748.html