[Libvir] [PATCH] Fix some memory leaks of virsh schedinfo

Hi, There are some memory leaks at the virsh schedinfo command. So I fix them. (e.g.) When the virDomainSetSchedulerParameters failed, the allocated memory as params is not freed. # valgrind --leak-check=full virsh schedinfo PV_RH5_8 --weight 0 ==18879== Memcheck, a memory error detector. ==18879== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. *snip* ==18879== 92 bytes in 1 blocks are definitely lost in loss record 6 of 23 ==18879== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==18879== by 0x80531D5: _vshMalloc (virsh.c:4201) ==18879== by 0x804BC44: cmdSchedinfo (virsh.c:1033) ==18879== by 0x80526CF: vshCommandRun (virsh.c:3839) ==18879== by 0x805452A: main (virsh.c:4741) ==18879== ==18879== LEAK SUMMARY: ==18879== definitely lost: 92 bytes in 1 blocks. ==18879== possibly lost: 0 bytes in 0 blocks. ==18879== still reachable: 14,234 bytes in 293 blocks. ==18879== suppressed: 0 bytes in 0 blocks. Signed-off-by: Saori Fukuta <fukuta.saori@jp.fujitsu.com> Thanks, Saori Fukuta

On Fri, Aug 17, 2007 at 08:41:41PM +0900, Saori Fukuta wrote:
Hi,
There are some memory leaks at the virsh schedinfo command. So I fix them.
(e.g.) When the virDomainSetSchedulerParameters failed, the allocated memory as params is not freed. # valgrind --leak-check=full virsh schedinfo PV_RH5_8 --weight 0 ==18879== Memcheck, a memory error detector. ==18879== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. *snip* ==18879== 92 bytes in 1 blocks are definitely lost in loss record 6 of 23 ==18879== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==18879== by 0x80531D5: _vshMalloc (virsh.c:4201) ==18879== by 0x804BC44: cmdSchedinfo (virsh.c:1033) ==18879== by 0x80526CF: vshCommandRun (virsh.c:3839) ==18879== by 0x805452A: main (virsh.c:4741) ==18879== ==18879== LEAK SUMMARY: ==18879== definitely lost: 92 bytes in 1 blocks. ==18879== possibly lost: 0 bytes in 0 blocks. ==18879== still reachable: 14,234 bytes in 293 blocks. ==18879== suppressed: 0 bytes in 0 blocks.
Signed-off-by: Saori Fukuta <fukuta.saori@jp.fujitsu.com>
Yes, makes perfect sense, for such kind of long routines with lot of data having one exit/cleanup point is the safest, applied ! Thanks I will commit as soon as I get the DNS back, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (2)
-
Daniel Veillard
-
Saori Fukuta