Bug 997765 - Virsh command cpu-baseline cause memory leak.
Virsh command cpu-baseline cause memory leak.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.5
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Peter Krempa
Virtualization Bugs
: Upstream
Depends On:
Blocks: 997798
  Show dependency treegraph
 
Reported: 2013-08-16 03:53 EDT by Hao Liu
Modified: 2014-04-04 16:57 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 997798 (view as bug list)
Environment:
Last Closed: 2014-04-04 16:57:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hao Liu 2013-08-16 03:53:07 EDT
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 04:39:31 EDT
commit f4ec8616410cea2b7dbe4c535c81cf70162a2939
Author: Peter Krempa <pkrempa@redhat.com>
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 03:20:30 EDT
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 Product and Program Management 2014-04-04 16:57:20 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.