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