Bug 1519759

Could you post the steps to reproduce the leaks and the libvirt version where they happened?

no.

Test on libvirt-3.9.0-4.el7.x86_64:

1.
This is mem leak in qemuStateInitialize:

==30865== 39 bytes in 1 blocks are definitely lost in loss record 881 of 2,037
==30865==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==30865==    by 0x861FE6F: __vasprintf_chk (in /usr/lib64/libc-2.17.so)
==30865==    by 0x552D7B5: UnknownInlinedFun (stdio2.h:210)
==30865==    by 0x552D7B5: virVasprintfInternal (virstring.c:708)
==30865==    by 0x552D8AA: virAsprintfInternal (virstring.c:729)
==30865==    by 0x23621DE2: qemuGetMemoryBackingBasePath (qemu_conf.c:1774)
==30865==    by 0x236683BC: qemuStateInitialize (qemu_driver.c:893)
==30865==    by 0x55D460E: virStateInitialize (libvirt.c:770)
==30865==    by 0x124E7A: daemonRunStateInit (libvirtd.c:834)
==30865==    by 0x5534321: virThreadHelper (virthread.c:206)
==30865==    by 0x82F3DD4: start_thread (in /usr/lib64/libpthread-2.17.so)
==30865==    by 0x860694C: clone (in /usr/lib64/libc-2.17.so)

Reproduce step:

 valgrind --leak-check=full /usr/sbin/libvirtd

2.
This is mem leak when parse tls element for vxhs network protocol:

==30802== 4 bytes in 1 blocks are definitely lost in loss record 12 of 679
==30802==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==30802==    by 0x6BD4B78: xmlStrndup (in /usr/lib64/libxml2.so.2.9.1)
==30802==    by 0x5562BFA: virDomainDiskSourceNetworkParse (domain_conf.c:8435)
==30802==    by 0x5562BFA: virDomainDiskSourceParse (domain_conf.c:8565)
==30802==    by 0x5563A64: virDomainDiskDefParseXML (domain_conf.c:9227)
==30802==    by 0x55847C4: virDomainDefParseXML (domain_conf.c:19217)
==30802==    by 0x5586E89: virDomainDefParseNode (domain_conf.c:20067)
==30802==    by 0x5586FB1: virDomainDefParse (domain_conf.c:20011)
==30802==    by 0x2367ABBE: qemuDomainDefineXMLFlags (qemu_driver.c:7392)
==30802==    by 0x55E876D: virDomainDefineXML (libvirt-domain.c:6160)
==30802==    by 0x14F7CA: remoteDispatchDomainDefineXML (remote_dispatch.h:4446)
==30802==    by 0x14F7CA: remoteDispatchDomainDefineXMLHelper (remote_dispatch.h:4424)
==30802==    by 0x5659AB1: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==30802==    by 0x5659AB1: virNetServerProgramDispatch (virnetserverprogram.c:307)
==30802==    by 0x160C7C: virNetServerProcessMsg (virnetserver.c:148)
==30802==    by 0x160C7C: virNetServerHandleJob (virnetserver.c:169)

Reproduce step:

define a guest with vxhs protocol disk:

    <disk type='network' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251' tls='yes'>
        <host name='192.168.0.1' port='9999'/>
      </source>
      <target dev='vda' bus='virtio'/>
      <serial>eb90327c-8302-4725-9e1b-4e85ed4dc251</serial>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>

3. 

This is mem leak when parse backingStore index element:

==31317== 2 bytes in 1 blocks are definitely lost in loss record 47 of 2,233
==31317==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==31317==    by 0x6BD4B78: xmlStrndup (in /usr/lib64/libxml2.so.2.9.1)
==31317==    by 0x5562F07: virDomainDiskBackingStoreParse.isra.66 (domain_conf.c:8628)
==31317==    by 0x55645BA: virDomainDiskDefParseXML (domain_conf.c:9579)
==31317==    by 0x55847C4: virDomainDefParseXML (domain_conf.c:19217)
==31317==    by 0x5587254: virDomainObjParseXML (domain_conf.c:19930)
==31317==    by 0x5587254: virDomainObjParseNode (domain_conf.c:20099)
==31317==    by 0x55876B4: virDomainObjParseFile (domain_conf.c:20118)
==31317==    by 0x5590B93: virDomainObjListLoadStatus (virdomainobjlist.c:515)
==31317==    by 0x5590B93: virDomainObjListLoadAllConfigs (virdomainobjlist.c:590)
==31317==    by 0x23668446: qemuStateInitialize (qemu_driver.c:912)
==31317==    by 0x55D460E: virStateInitialize (libvirt.c:770)
==31317==    by 0x124E7A: daemonRunStateInit (libvirtd.c:834)
==31317==    by 0x5534321: virThreadHelper (virthread.c:206)

Reproduce step:

prepare a guest which have external snapshot and use valgrind start libvirtd:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.test2'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.qcow2'/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>

# service libvirtd stop

# valgrind --leak-check=full /usr/sbin/libvirtd

Retest with the same steps in comment 4 on libvirt-3.9.0-5.el7.x86_64, didn't find any memory leak. Verify this bug.

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.

https://access.redhat.com/errata/RHEA-2018:0704