==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)
/* 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.
Leak #1:
==12891== 80 bytes in 1 blocks are definitely lost in loss record 949 of 1,360 valgrind/ vgpreload_ memcheck- amd64-linux. so)
==12891== at 0x4C2CC70: calloc (in /usr/lib/
==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 {
virErrorLevel level; /* 0x10 0x4 */
int code; /* 0 0x4 */
int domain; /* 0x4 0x4 */
char * message; /* 0x8 0x8 */
/* XXX 4 bytes hole, try to pack */
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 */
/* 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 ata(), which is a thread "destructor" set in the pthread
in virLastErrFreeD
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.