Bug 1011330

Leak c) have already been fixed with commit e4697b9 in upstream.

https://www.redhat.com/archives/libvir-list/2013-September/msg01245.html

b) is not a memory leak as the domain is still running (def = NULL is correct, the pointer was stolen by virDomainObjListAdd(). I sent patches for a) and d).

The leaks are now fixed upstream as of v1.1.3-rc1-13-g9e03f31 by the following commits:

commit e4697b92abaad16e8e6b41a1e55be9b084d48d5a
Author: Daniel P. Berrange <berrange>
Date:   Mon Sep 23 12:46:25 2013 +0100

    Fix typo in identity code which is pre-requisite for CVE-2013-4311
    
    The fix for CVE-2013-4311 had a pre-requisite enhancement
    to the identity code
    
      commit db7a5688c05f3fd60d9d2b74c72427eb9ee9c176
      Author: Daniel P. Berrange <berrange>
      Date:   Thu Aug 22 16:00:01 2013 +0100
    
        Also store user & group ID values in virIdentity
    
    This had a typo which caused the group ID to overwrite the
    user ID string. This meant any checks using this would have
    the wrong ID value. This only affected the ACL code, not the
    initial polkit auth. It also leaked memory.
    
    Signed-off-by: Daniel P. Berrange <berrange>

commit 833cdab6d2ad7521c954948adf3c7d3c3b42ae9f
Author: Jiri Denemark <jdenemar>
Date:   Fri Sep 27 15:07:38 2013 +0200

    qemu: Don't leak reference to virQEMUDriverConfigPtr
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1011330 (case D)
    
    qemuProcessStart created two references to virQEMUDriverConfigPtr before
    calling fork():
    
        cfg = virQEMUDriverGetConfig(driver);
        ...
        hookData.cfg = virObjectRef(cfg);
    
    However, the child only unreferenced hookData.cfg and the parent only
    removed the cfg reference. That said, we don't need to increment the
    reference counter when assigning cfg to hookData. Both the child and the
    parent will correctly remove the reference on cfg (the child will do
    that through hookData).
    
    Signed-off-by: Jiri Denemark <jdenemar>

commit 9e03f313b80d6b7daef90235b607e7ed80dd7235
Author: Jiri Denemark <jdenemar>
Date:   Fri Sep 27 15:34:43 2013 +0200

    qemu: Free all driver data in qemuStateCleanup
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1011330 (case A)
    
    While activeScsiHostdevs and webSocketPorts were allocated in
    qemuStateInitialize, they were not freed in qemuStateCleanup.
    
    Signed-off-by: Jiri Denemark <jdenemar>

Hi All,

For one memory leak issue below, I have verified using patch http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-September/msg00742.html
in https://bugzilla.redhat.com/show_bug.cgi?id=1006272#c6

I can't find below mem leak issue with libvirt-1.1.1-7.el7.x86_64.

Reproduced steps are same as https://bugzilla.redhat.com/show_bug.cgi?id=1011330#c0

[root@localhost ~]# rpm -q libvirt
libvirt-1.1.1-7.el7.x86_64

305 ==9402== 6 bytes in 3 blocks are definitely lost in loss record 137 of 1,775
306 ==9402==    at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
307 ==9402==    by 0x7E7C40F: __vasprintf_chk (in /usr/lib64/libc-2.17.so)
308 ==9402==    by 0x50BDE65: virVasprintfInternal (stdio2.h:210)
309 ==9402==    by 0x50BDF4A: virAsprintfInternal (virstring.c:358)
310 ==9402==    by 0x519A9B6: virNetServerClientGetIdentity (virnetserverclient.c:677)
311 ==9402==    by 0x519CD1D: virNetServerProgramDispatch (virnetserverprogram.c:419)
312 ==9402==    by 0x5197BC7: virNetServerHandleJob (virnetserver.c:165)
313 ==9402==    by 0x50C18F4: virThreadPoolWorker (virthreadpool.c:144)
314 ==9402==    by 0x50C1370: virThreadHelper (virthreadpthread.c:161)
315 ==9402==    by 0x7753C52: start_thread (in /usr/lib64/libpthread-2.17.so)
316 ==9402==    by 0x7E6513C: clone (in /usr/lib64/libc-2.17.so)

But, still have a similar leak as below:
464 ==10172== 108 bytes in 2 blocks are definitely lost in loss record 1,107 of 1,777
465 ==10172==    at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
466 ==10172==    by 0x7DF6349: strdup (in /usr/lib64/libc-2.17.so)
467 ==10172==    by 0x7539FB4: selinux_raw_to_trans_context (in /usr/lib64/libselinux.so.1)
468 ==10172==    by 0x753A882: getpeercon (in /usr/lib64/libselinux.so.1)
469 ==10172==    by 0x51A3BBD: virNetSocketGetSELinuxContext (virnetsocket.c:1182)
470 ==10172==    by 0x519AC5C: virNetServerClientGetIdentity (virnetserverclient.c:708)
471 ==10172==    by 0x519CDAD: virNetServerProgramDispatch (virnetserverprogram.c:419)
472 ==10172==    by 0x5197C27: virNetServerHandleJob (virnetserver.c:165)
473 ==10172==    by 0x50C18F4: virThreadPoolWorker (virthreadpool.c:144)
474 ==10172==    by 0x50C1370: virThreadHelper (virthreadpthread.c:161)
475 ==10172==    by 0x7753C52: start_thread (in /usr/lib64/libpthread-2.17.so)
476 ==10172==    by 0x7E6513C: clone (in /usr/lib64/libc-2.17.so)

Hi Jiri,

I verified fix of leak A, C, D using
libvirt-1.1.1-8.el7.x86_64

But got following leak along with the one mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=1011330#c6

==12538== 832 (32 direct, 800 indirect) bytes in 1 blocks are definitely lost in loss record 609 of 646
==12538==    at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12538==    by 0x75456A1: selabel_subs_init (label.c:100)
==12538==    by 0x75413A8: init (label_file.c:499)
==12538==    by 0x7545850: selabel_open (label.c:182)
==12538==    by 0x520B4E8: virSecuritySELinuxSecurityDriverOpen (security_selinux.c:491)
==12538==    by 0x5208033: virSecurityManagerNewDriver (security_manager.c:98)
==12538==    by 0x1BA569EB: qemuStateInitialize (qemu_driver.c:358)
==12538==    by 0x5136779: virStateInitialize (libvirt.c:834)
==12538==    by 0x11C1CA: daemonRunStateInit (libvirtd.c:906)
==12538==    by 0x50C5390: virThreadHelper (virthreadpthread.c:161)
==12538==    by 0x775CDE2: start_thread (pthread_create.c:308)
==12538==    by 0x7E6F1AC: clone (clone.S:113)

Are these need to be fixed?

It would be nice if that was fixed but it's not really important. It leaks a memory that is allocated when libvirtd starts and is used all the time the daemon is running. Freeing the memory when the daemon goes down would be nice and clean but not doing so does not actually leak any memory anyway.

Thanks Jiri. Considering all leaks mentioned in original post are fixed and verified, I mark this thread as VERIFIED.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.