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