]> xenbits.xensource.com Git - libvirt.git/commitdiff
blockjob: avoid memory leak during block pivot
authorEric Blake <eblake@redhat.com>
Wed, 6 Aug 2014 20:48:59 +0000 (14:48 -0600)
committerEric Blake <eblake@redhat.com>
Thu, 7 Aug 2014 18:17:02 +0000 (12:17 -0600)
Valgrind caught a memory leak:

==2018== 9 bytes in 1 blocks are definitely lost in loss record 143 of 927
==2018==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2018==    by 0x8C42369: strdup (strdup.c:42)
==2018==    by 0x50EACC9: virStrdup (virstring.c:676)
==2018==    by 0x50E79E5: virStorageSourceCopy (virstoragefile.c:1845)
==2018==    by 0x20A3FAA7: qemuDomainBlockCommit (qemu_driver.c:15620)
==2018==    by 0x51DC6B2: virDomainBlockCommit (libvirt.c:20092)

I traced it to the fact that blockcopy and blockcommit end up
reparsing a backing chain on pivot, but the chain parsing code
doesn't gracefully handle the case where the backing file is
already known.

I'm not exactly sure when this was introduced, but suspect that the
refactoring in commit 9944b71 and friends that moved towards probing
in-place rather than into a temporary structure are part of the cause.

* src/util/virstoragefile.c (virStorageFileGetMetadataInternal):
Don't leak any prior value.

Signed-off-by: Eric Blake <eblake@redhat.com>
src/util/virstoragefile.c

index 3da9073dffdc999905206799d4855aa7a4c7b7e5..5b6b2f58ecd2148f706c2a0e87a1d2cca6b7f62d 100644 (file)
@@ -817,6 +817,7 @@ virStorageFileGetMetadataInternal(virStorageSourcePtr meta,
             goto cleanup;
     }
 
+    VIR_FREE(meta->backingStoreRaw);
     if (fileTypeInfo[meta->format].getBackingStore != NULL) {
         int store = fileTypeInfo[meta->format].getBackingStore(&meta->backingStoreRaw,
                                                          backingFormat,