Bug 997765

Summary: Virsh command cpu-baseline cause memory leak.
Product: Red Hat Enterprise Linux 6 Reporter: Hao Liu <hliu>
Component: libvirtAssignee: Peter Krempa <pkrempa>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.5CC: acathrow, dyuan, hliu, lsu, mzhan, pkrempa, zsong
Target Milestone: rcKeywords: Upstream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 997798 (view as bug list) Environment:
Last Closed: 2014-04-04 20:57:20 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:    
Bug Blocks: 997798    

Description Hao Liu 2013-08-16 07:53:07 UTC
Description of problem:
virsh command cpu-baseline cause memory leak.

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

How reproducible:
always

Steps to Reproduce:
1. make a cpu profile xml or capabilities xml.
# virsh capabilities > cap.xml

2. check memory leak for cpu-baseline
# valgrind -v --leak-check=full virsh cpu-baseline cap.xml

valgrind result:
==22406== 8 bytes in 1 blocks are definitely lost in loss record 8 of 103
==22406==    at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==22406==    by 0x4E8845B: virAllocN (memory.c:128)
==22406==    by 0x4E9D786: virXPathNodeSet (xml.c:601)
==22406==    by 0x412AAE: cmdCPUBaseline (virsh-domain.c:5298)
==22406==    by 0x40D240: vshCommandRun (virsh.c:1652)
==22406==    by 0x410B4A: main (virsh.c:3093)
==22406==
==22406== LEAK SUMMARY:
==22406==    definitely lost: 8 bytes in 1 blocks
==22406==    indirectly lost: 0 bytes in 0 blocks
==22406==      possibly lost: 0 bytes in 0 blocks
==22406==    still reachable: 139,233 bytes in 1,575 blocks
==22406==         suppressed: 0 bytes in 0 blocks



Expected result:
no memory leak

Comment 1 Peter Krempa 2013-08-16 08:39:31 UTC
commit f4ec8616410cea2b7dbe4c535c81cf70162a2939
Author: Peter Krempa <pkrempa>
Date:   Fri Aug 16 10:33:30 2013 +0200

    virsh-domain: Fix memleak in cmdCPUBaseline
    
    https://bugzilla.redhat.com/show_bug.cgi?id=997765
    
    ==1349431== 8 bytes in 1 blocks are definitely lost in loss record 11 of 760
    ==1349431==    at 0x4C2A554: calloc (vg_replace_malloc.c:593)
    ==1349431==    by 0x4E9AA3E: virAllocN (in /usr/lib64/libvirt.so.0.1001.1)
    ==1349431==    by 0x4EF28C4: virXPathNodeSet (in /usr/lib64/libvirt.so.0.1001.1)
    ==1349431==    by 0x130B83: cmdCPUBaseline (in /usr/bin/virsh)
    ==1349431==    by 0x12C608: vshCommandRun (in /usr/bin/virsh)
    ==1349431==    by 0x12889A: main (in /usr/bin/virsh)

Comment 2 zhengqin 2013-09-13 07:20:30 UTC
Could reproduce with the described steps on selected component (if applicable):
Red Hat Enterprise Linux Server release 6.5 Beta
libvirt-0.10.2-22.el6.x86_64
kernel-2.6.32-412.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.394.el6.x86_64
 
Reproduce steps:
1. make a cpu profile xml or capabilities xml.
# virsh capabilities > cap.xml

2. check memory leak for cpu-baseline
# valgrind -v --leak-check=full virsh cpu-baseline cap.xml

valgrind result:
==22406== 8 bytes in 1 blocks are definitely lost in loss record 8 of 103
==22406==    at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==22406==    by 0x4E8845B: virAllocN (memory.c:128)
==22406==    by 0x4E9D786: virXPathNodeSet (xml.c:601)
==22406==    by 0x412AAE: cmdCPUBaseline (virsh-domain.c:5298)
==22406==    by 0x40D240: vshCommandRun (virsh.c:1652)
==22406==    by 0x410B4A: main (virsh.c:3093)
==22406==
==22406== LEAK SUMMARY:
==22406==    definitely lost: 8 bytes in 1 blocks
==22406==    indirectly lost: 0 bytes in 0 blocks
==22406==      possibly lost: 0 bytes in 0 blocks
==22406==    still reachable: 139,233 bytes in 1,575 blocks
==22406==         suppressed: 0 bytes in 0 blocks

Comment 4 RHEL Program Management 2014-04-04 20:57:20 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.