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