提交 7620b422 编写于 作者: E Eric Blake

blockjob: avoid memory leak during block pivot

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 9944b710 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: NEric Blake <eblake@redhat.com>
(cherry picked from commit a595a005)
上级 2151695a
......@@ -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,
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册