Comment 2 for bug 1844455

Revision history for this message
Guilherme G. Piccoli (gpiccoli) wrote : Re: Memory leak on libvirt 1.3.1

Leak #1:

==12891== 80 bytes in 1 blocks are definitely lost in loss record 949 of 1,360
==12891== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12891== by 0x50A5299: virAlloc (viralloc.c:144)
==12891== by 0x50C1C63: virLastErrorObject (virerror.c:240)
==12891== by 0x50C4F88: virResetLastError (virerror.c:412)
==12891== by 0x51B786C: virConnectOpen (libvirt.c:1139)

From pahole:

struct _virError {
        int code; /* 0 0x4 */
        int domain; /* 0x4 0x4 */
        char * message; /* 0x8 0x8 */
        virErrorLevel level; /* 0x10 0x4 */

        /* XXX 4 bytes hole, try to pack */

        virConnectPtr conn; /* 0x18 0x8 */
        virDomainPtr dom; /* 0x20 0x8 */
        char * str1; /* 0x28 0x8 */
        char * str2; /* 0x30 0x8 */
        char * str3; /* 0x38 0x8 */
        /* --- cacheline 1 boundary (64 bytes) --- */
        int int1; /* 0x40 0x4 */
        int int2; /* 0x44 0x4 */
        virNetworkPtr net; /* 0x48 0x8 */

        /* size: 80, cachelines: 2, members: 12 */
        /* sum members: 76, holes: 1, sum holes: 4 */
        /* last cacheline: 16 bytes */
};

The _virError struct (in the form of virErrorPtr typedef) is expected to be freed
in virLastErrFreeData(), which is a thread "destructor" set in the pthread
creation. It should be called when thread exists (by pthread_exit() or something
analog), but can be skipped if process main() function returns.
So, hypothesis here are:

1) There was a process exist that led to this thread data getting leaked
2) Valgrind should be ended (with SIGTERM) in order to collect the thread
destructor execution, so this is a false/temporary leak.