On 08/06/14 23:12, Eric Blake wrote:
> 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@xxxxxxxxxx>
> ---
> src/util/virstoragefile.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
> index 3da9073..5b6b2f5 100644
> --- a/src/util/virstoragefile.c
> +++ b/src/util/virstoragefile.c
> @@ -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,
>
ACK
Peter
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list