Bug 735008 - memory leak on volume creation with non-existent backing file
Summary: memory leak on volume creation with non-existent backing file
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-01 07:22 UTC by Nan Zhang
Modified: 2011-12-06 11:27 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.9.4-8.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-12-06 11:27:51 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

Description Nan Zhang 2011-09-01 07:22:49 UTC
Description of problem:
There is a leaked reference when fail to create volume with non-existent backing file.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
# virsh vol-list default
Name                 Path
foo.img              /var/lib/libvirt/images/foo.img
test.img             /var/lib/libvirt/images/test.img
win7.img             /var/lib/libvirt/images/win7.img

# virsh vol-create-as default foo-new.img 4G --allocation 0 --format qcow2 --backing-vol foo.qcow2 --backing-vol-format qcow2
error: failed to get vol 'foo.qcow2'
error: Storage volume not found: no storage vol with matching path

error: Failed to disconnect from the hypervisor, 1 leaked reference(s)

Actual results:
There is a leaked reference error occurs.

Expected results:
No leaked reference errors.

Additional info:

Comment 1 Alex Jia 2011-09-02 07:45:40 UTC
Patch for upstream:

commit 59d4b170fc422d5f86977811b8b91b15ee133e94
Author: Alex Jia <ajia@redhat.com>
Date:   Fri Sep 2 01:12:00 2011 +0800

    virsh: avoid memory leak on cmdVolCreateAs
    * tools/virsh.c: fix memory leak on cmdVolCreateAs function.
    * Detected in valgrind run:
    ==4746== 48 (40 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 26 of 52
    ==4746==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
    ==4746==    by 0x4C76E51: virAlloc (memory.c:101)
    ==4746==    by 0x4CD9418: virGetStoragePool (datatypes.c:592)
    ==4746==    by 0x4D21367: remoteStoragePoolLookupByName (remote_driver.c:4126)
    ==4746==    by 0x4CE42B0: virStoragePoolLookupByName (libvirt.c:10232)
    ==4746==    by 0x40C276: vshCommandOptPoolBy (virsh.c:13660)
    ==4746==    by 0x40CA37: cmdVolCreateAs (virsh.c:8094)
    ==4746==    by 0x412AF2: vshCommandRun (virsh.c:13770)
    ==4746==    by 0x422F11: main (virsh.c:15127)
    ==4746== 1,011 bytes in 1 blocks are definitely lost in loss record 45 of 52
    ==4746==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
    ==4746==    by 0x4A06167: realloc (vg_replace_malloc.c:525)
    ==4746==    by 0x4C76ECB: virReallocN (memory.c:161)
    ==4746==    by 0x4C60319: virBufferGrow (buf.c:72)
    ==4746==    by 0x4C606AA: virBufferAdd (buf.c:106)
    ==4746==    by 0x40CB37: cmdVolCreateAs (virsh.c:8118)
    ==4746==    by 0x412AF2: vshCommandRun (virsh.c:13770)
    ==4746==    by 0x422F11: main (virsh.c:15127)
    ==4746== LEAK SUMMARY:
    ==4746==    definitely lost: 1,051 bytes in 2 blocks
    ==4746==    indirectly lost: 8 bytes in 1 blocks
    ==4746==      possibly lost: 0 bytes in 0 blocks
    ==4746==    still reachable: 390,767 bytes in 1,373 blocks
    ==4746==         suppressed: 0 bytes in 0 blocks
    * How to reproduce?
    % valgrind -v --leak-check=full virsh vol-create-as default foo.img 10M \
      --allocation 0 --format qcow2 --backing-vol bar.img
    Notes: bar.img doesn't exist.
    Signed-off-by: Alex Jia <ajia@redhat.com>

Comment 5 errata-xmlrpc 2011-12-06 11:27:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.