On 08/20/2013 05:08 AM, Osier Yang wrote:
> Introduced by commit e0139e30444. virStorageVolDefFree free'ed the
> pointers that are still used by the added volume object, this changes
> it back to VIR_FREE.
> ---
> src/storage/storage_driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
> index 63a954b..883e4e9 100644
> --- a/src/storage/storage_driver.c
> +++ b/src/storage/storage_driver.c
> @@ -1618,7 +1618,7 @@ storageVolCreateXML(virStoragePoolPtr obj,
> cleanup:
> virObjectUnref(volobj);
> virStorageVolDefFree(voldef);
> - virStorageVolDefFree(buildvoldef);
> + VIR_FREE(buildvoldef);
> if (pool)
> virStoragePoolObjUnlock(pool);
> return ret;
>
Perhaps a comment "/* Free just the shallow copy of buildvoldef */".
Just for the clarity of why you wouldn't want to use virStorageVolDefFree().
Of course the same possible other solution applies here as well as it
did in your 1/2 patch where you define a local allocation variable to
handle the pool->def->{allocation|available} math. That way buildvoldef
moves back inside the "if (backend->buildVol)"...
ACK either way though.
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list