If someone has the time ... I am seeing a memory leak in this code path.
The leak seems to be triggerable by shutting down a VM:
==4717== 40 bytes in 1 blocks are definitely lost in loss record 547 of
1,014
==4717== at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==4717== by 0x38EC27FC01: strdup (strdup.c:43)
==4717== by 0x4EA55E0: virCopyError (virterror.c:255)
==4717== by 0x4EA58B1: virCopyLastError (virterror.c:356)
==4717== by 0x4CB4B6: qemuMonitorIO (qemu_monitor.c:646)
==4717== by 0x4E80C7F: virEventPollDispatchHandles (event_poll.c:490)
==4717== by 0x4E8150B: virEventPollRunOnce (event_poll.c:637)
==4717== by 0x4E7F5B7: virEventRunDefaultImpl (event.c:247)
==4717== by 0x4FA4F50: virNetServerRun (virnetserver.c:713)
==4717== by 0x4221AF: main (libvirtd.c:1133)
My guess is the leak is related to the initialization of the error
structure as for example here:
int
virConnCopyLastError(virConnectPtr conn, virErrorPtr to)
{
/* We can't guarantee caller has initialized it to zero */
memset(to, 0, sizeof(*to));
if (conn == NULL)
return -1;
virMutexLock(&conn->lock);
if (conn->err.code == VIR_ERR_OK)
virResetError(to);
else
After memset'ting 'to' to all zeros, the call to virResetError() seems
pointless... Such memsets are also in other places potentially
overwriting previously allocated pointers...
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
