Bug 808979 - memory leak in virDomainGetVcpus / virsh vcpuinfo
memory leak in virDomainGetVcpus / virsh vcpuinfo
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-02 01:28 EDT by Laine Stump
Modified: 2012-06-20 02:51 EDT (History)
7 users (show)

See Also:
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 02:51:51 EDT
Type: ---
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 Laine Stump 2012-04-02 01:28:47 EDT
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 02:16:47 EDT
Fixed upstream:

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

    qemu: fix memory leak in virDomainGetVcpus
Comment 5 dyuan 2012-04-06 06:17:33 EDT
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 02:51:51 EDT
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

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