Bug 808979

Summary: memory leak in virDomainGetVcpus / virsh vcpuinfo
Product: Red Hat Enterprise Linux 6 Reporter: Laine Stump <laine>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: acathrow, ajia, dyasny, dyuan, mzhan, rwu, veillard
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-0.9.10-10.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 06:51:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Laine Stump 2012-04-02 05:28:47 UTC
Description of problem:

Each time virsh vcpuinfo is run (or virDomainGetVcpus is called) a small amount of memory is leaked.

Version-Release number of selected component (if applicable):

Every version of libvirt between 0.7.5 and 0.9.10-9


How reproducible: 100%

Steps to Reproduce:

1) stop libvirtd - "/etc/init.d/libvirtd stop"

2) run libvirtd under valgrind - "valgrind --leak-check=full libvirtd" 

3) run "virsh vcpuinfo $guest" many times ($guest is the name of some active guest)

4) ctl-C out of the valgrind commend in step 2.
  
Actual results:

One "cpuset" (128 bytes in the case of my machine, which has 6 cores) will be leaked for each time virsh vcpuinfo is called - you will see a record similar to the following in the valgrind output:

==19980== 6,400 bytes in 50 blocks are definitely lost in loss record 911 of 924
==19980==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==19980==    by 0x3CAAC65860: virProcessInfoGetAffinity (processinfo.c:120)
==19980==    by 0x460DC0: qemudDomainGetVcpus (qemu_driver.c:3781)
==19980==    by 0x3CAACF9710: virDomainGetVcpus (libvirt.c:8915)
==19980==    by 0x43B519: remoteDispatchDomainGetVcpusHelper (remote.c:1498)
==19980==    by 0x3CAAD48354: virNetServerProgramDispatch (virnetserverprogram.c:416)
==19980==    by 0x3CAAD42E10: virNetServerHandleJob (virnetserver.c:164)
==19980==    by 0x3CAAC6B7ED: virThreadPoolWorker (threadpool.c:144)
==19980==    by 0x3CAAC6AE95: virThreadHelper (threads-pthread.c:161)
==19980==    by 0x32E0207D8F: start_thread (pthread_create.c:309)
==19980==    by 0x32DFEF0F5C: clone (clone.S:115)

(I had run "virsh vcpuinfo $guest" 50 times)

Expected results:

There should be no such record in the valgrind output.

Solution:

The problem is caused by virProcessInfoGetAffinity calling CPU_ALLOC() but not calling CPU_FREE(). I'm posting a fix upstream momentarily, and will enter the commit ID here once it's been pushed.

Comment 1 Laine Stump 2012-04-02 06:16:47 UTC
Fixed upstream:

commit a4650316d104ca559101d2944a9ecb43d35b7d72
Author: Laine Stump <laine>
Date:   Mon Apr 2 00:26:44 2012 -0400

    qemu: fix memory leak in virDomainGetVcpus

Comment 5 dyuan 2012-04-06 10:17:33 UTC
Verified PASS with libvirt-0.9.10-10.el6.

==17660== LEAK SUMMARY:
==17660==    definitely lost: 0 bytes in 0 blocks
==17660==    indirectly lost: 0 bytes in 0 blocks
==17660==      possibly lost: 4,416 bytes in 12 blocks
==17660==    still reachable: 791,628 bytes in 9,164 blocks
==17660==         suppressed: 0 bytes in 0 blocks
==17660== Reachable blocks (those to which a pointer was found) are not shown.
==17660== To see them, rerun with: --leak-check=full --show-reachable=yes
==17660== 
==17660== For counts of detected and suppressed errors, rerun with: -v
==17660== Use --track-origins=yes to see where uninitialised values come from
==17660== ERROR SUMMARY: 60 errors from 15 contexts (suppressed: 31 from 9)

Reproduced it with libvirt-0.9.10-9.el6.
==20534== LEAK SUMMARY:
==20534==    definitely lost: 3,072 bytes in 24 blocks
==20534==    indirectly lost: 0 bytes in 0 blocks
==20534==      possibly lost: 4,784 bytes in 13 blocks
==20534==    still reachable: 802,684 bytes in 9,541 blocks
==20534==         suppressed: 0 bytes in 0 blocks
==20534== Reachable blocks (those to which a pointer was found) are not shown.
==20534== To see them, rerun with: --leak-check=full --show-reachable=yes
==20534== 
==20534== For counts of detected and suppressed errors, rerun with: -v
==20534== Use --track-origins=yes to see where uninitialised values come from
==20534== ERROR SUMMARY: 73 errors from 16 contexts (suppressed: 31 from 9)

Comment 7 errata-xmlrpc 2012-06-20 06:51:51 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