There were 2 places where memory was allocated with g_new0 and was
later freed with g_slice_free. This commit uses g_slice_new0 instead.
After this, there are no other occurrences of g_new0 in gobject/ so
the rest of the codebase should be safe from this issue.
---
libvirt-gobject/libvirt-gobject-storage-pool.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libvirt-gobject/libvirt-gobject-storage-pool.c b/libvirt-gobject/libvirt-gobject-storage-pool.c
index f46dc32..0ba1768 100644
--- a/libvirt-gobject/libvirt-gobject-storage-pool.c
+++ b/libvirt-gobject/libvirt-gobject-storage-pool.c
@@ -621,7 +621,7 @@ void gvir_storage_pool_build_async (GVirStoragePool *pool,
GSimpleAsyncResult *res;
StoragePoolBuildData *data;
- data = g_new0(StoragePoolBuildData, 1);
+ data = g_slice_new0(StoragePoolBuildData);
data->flags = flags;
res = g_simple_async_result_new(G_OBJECT(pool),
@@ -721,7 +721,7 @@ void gvir_storage_pool_start_async (GVirStoragePool *pool,
GSimpleAsyncResult *res;
StoragePoolBuildData *data;
- data = g_new0(StoragePoolBuildData, 1);
+ data = g_slice_new0(StoragePoolBuildData);
data->flags = flags;
res = g_simple_async_result_new(G_OBJECT(pool),
--
1.7.7.5
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list