In the function an helper to build the dnsmasq config file is used. The content to be stored then into the config file is kept in @configstr variable. However, once written, it's never freed and as soon as the control reaches the 'return' line, the variable (and hence allocated memory handle) will go off the scope and is leaked. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- src/network/bridge_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 3423a45..fd4dfc9 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -1061,6 +1061,7 @@ networkBuildDhcpDaemonCommandLine(virNetworkObjPtr network, *cmdout = cmd; ret = 0; cleanup: + VIR_FREE(configstr); return ret; } -- 1.8.3.2

The name of the dnsmasq's config file is initialized and passed to virCommand. However, the virCommand creates a copy, so we are responsible for freeing the @configfile ourselves. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- src/network/bridge_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index fd4dfc9..4298576 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -1061,6 +1061,7 @@ networkBuildDhcpDaemonCommandLine(virNetworkObjPtr network, *cmdout = cmd; ret = 0; cleanup: + VIR_FREE(configfile); VIR_FREE(configstr); return ret; } -- 1.8.3.2

These two chunks had to be part of df4283a55bf. But for some unclear reason, the weren't. Anyway, these two variables are not used anywhere within function. They're initialized to NULL and then VIR_FREE()-d. And there's no reason do do two NOPs, right? Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- src/util/virpci.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/util/virpci.c b/src/util/virpci.c index a41a22b..8a3a492 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -1085,8 +1085,6 @@ virPCIDeviceBindToStub(virPCIDevicePtr dev, char *stubDriverPath = NULL; char *driverLink = NULL; - char *oldDriverPath = NULL; - char *oldDriverName = NULL; char *path = NULL; /* reused for different purposes */ const char *newDriverName = NULL; @@ -1217,8 +1215,6 @@ remove_id: cleanup: VIR_FREE(stubDriverPath); VIR_FREE(driverLink); - VIR_FREE(oldDriverPath); - VIR_FREE(oldDriverName); VIR_FREE(path); if (newDriverName && -- 1.8.3.2

Even though currently we are freeing the pool of worker threads at the daemon very end, nothing holds us back in joining the worker threads. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- src/util/virthreadpool.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/util/virthreadpool.c b/src/util/virthreadpool.c index b1e2c0c..99f36ec 100644 --- a/src/util/virthreadpool.c +++ b/src/util/virthreadpool.c @@ -241,6 +241,9 @@ void virThreadPoolFree(virThreadPoolPtr pool) { virThreadPoolJobPtr job; bool priority = false; + size_t i; + size_t nWorkers = pool->nWorkers; + size_t nPrioWorkers = pool->nPrioWorkers; if (!pool) return; @@ -262,6 +265,12 @@ void virThreadPoolFree(virThreadPoolPtr pool) VIR_FREE(job); } + for (i = 0; i < nWorkers; i++) + virThreadJoin(&pool->workers[i]); + + for (i = 0; i < nPrioWorkers; i++) + virThreadJoin(&pool->prioWorkers[i]); + VIR_FREE(pool->workers); virMutexUnlock(&pool->mutex); virMutexDestroy(&pool->mutex); -- 1.8.3.2

The @list->callbacks is an array that is inflated whenever a new event is added, e.g. via virDomainEventCallbackListAddID(). However, when we are freeing the array, we free the items within it but forgot to actually free it. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- src/conf/domain_event.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/conf/domain_event.c b/src/conf/domain_event.c index 16ae92b..19e3920 100644 --- a/src/conf/domain_event.c +++ b/src/conf/domain_event.c @@ -147,6 +147,7 @@ virDomainEventCallbackListFree(virDomainEventCallbackListPtr list) (*freecb)(list->callbacks[i]->opaque); VIR_FREE(list->callbacks[i]); } + VIR_FREE(list->callbacks); VIR_FREE(list); } -- 1.8.3.2

In the qemuProcessReconnectHelper() a new thread that do all the interesting work is spawned. The rationale is to not block the daemon startup process in case of unresponsive qemu. However, the thread handler is a local variable which gets lost once the control goes out of scope. Hence, the thread gets leaked. We can avoid this if the thread isn't make joinable. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- src/qemu/qemu_process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index e34f542..f698d47 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3281,7 +3281,7 @@ qemuProcessReconnectHelper(virDomainObjPtr obj, */ virConnectRef(data->conn); - if (virThreadCreate(&thread, true, qemuProcessReconnect, data) < 0) { + if (virThreadCreate(&thread, false, qemuProcessReconnect, data) < 0) { virConnectClose(data->conn); -- 1.8.3.2