Hide Forgot
Description of problem: memory leak in cmdVolPath code. Version-Release number of selected component (if applicable): # uname -r 2.6.32-160.el6.x86_64 # rpm -q libvirt libvirt-0.9.3-8.el6.x86_64 How reproducible: always Steps to Reproduce: 1.virsh pool-list and make sure default pool is active 2.dd if=/dev/zero of=/var/lib/libvirt/images/foo.img count=1 bs=10M 3.virsh pool-refresh default 4.valgrind -v --leak-check=full virsh vol-path --vol /var/lib/libvirt/images/foo.img Actual results: ==16436== 32 bytes in 1 blocks are definitely lost in loss record 7 of 22 ==16436== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==16436== by 0x386A314B3D: xdr_string (in /lib64/libc-2.12.so) ==16436== by 0x3DF8CD770D: xdr_remote_nonnull_string (remote_protocol.c:30) ==16436== by 0x3DF8CD7EC8: xdr_remote_storage_vol_get_path_ret (remote_protocol.c:2952) ==16436== by 0x3DF8CDF161: virNetMessageDecodePayload (virnetmessage.c:286) ==16436== by 0x3DF8CDE9E5: virNetClientProgramCall (virnetclientprogram.c:318) ==16436== by 0x3DF8CC28A2: call (remote_driver.c:3929) ==16436== by 0x3DF8CC8412: remoteStorageVolGetPath (remote_client_bodies.h:5219) ==16436== by 0x3DF8C9BF14: virStorageVolGetPath (libvirt.c:11389) ==16436== by 0x418ECA: cmdVolPath (virsh.c:8754) ==16436== by 0x410CC2: vshCommandRun (virsh.c:12758) ==16436== by 0x41F286: main (virsh.c:14110) ==16436== ==16436== LEAK SUMMARY: ==16436== definitely lost: 32 bytes in 1 blocks Expected results: avoid memory leak. Additional info: I have sent a patch to upstream and wait for developers review
This is a patch: https://www.redhat.com/archives/libvir-list/2011-July/msg01877.html
commit 1768bf63edf96c66aba25ddf85b2bf3a6b842630 Author: Alex Jia <ajia> Date: Thu Jul 28 10:42:51 2011 +0800 virsh: fix memory leak in cmdVolPath code * tools/virsh.c: avoid memory leak in cmdVolPath. * src/libvirt.c: Add doc for virStorageVolGetPath to tell one must free() the returned path after use. * how to reproduce? % dd if=/dev/zero of=/var/lib/libvirt/images/foo.img count=1 bs=10M % virsh pool-refresh default % valgrind -v --leak-check=full virsh vol-path --vol \ /var/lib/libvirt/images/foo.img * actual results: Detected in valgrind run: ==16436== 32 bytes in 1 blocks are definitely lost in loss record 7 of 22 ==16436== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==16436== by 0x386A314B3D: xdr_string (in /lib64/libc-2.12.so) ==16436== by 0x3DF8CD770D: xdr_remote_nonnull_string (remote_protocol.c:3 ==16436== by 0x3DF8CD7EC8: xdr_remote_storage_vol_get_path_ret % virsh pool-refresh default % valgrind -v --leak-check=full virsh vol-path --vol \ /var/lib/libvirt/images/foo.img Signed-off-by: Alex Jia <ajia> Patch pushed to upstream, move to POST.
tested with libvirt-0.9.4-0rc2.el6.x86_64 1.virsh pool-list and make sure default pool is active 2.dd if=/dev/zero of=/var/lib/libvirt/images/foo.img count=1 bs=10M 3.virsh pool-refresh default 4.valgrind -v --leak-check=full virsh vol-path --vol /var/lib/libvirt/images/foo.img ==13559== ==13559== HEAP SUMMARY: ==13559== in use at exit: 331,401 bytes in 53 blocks ==13559== total heap usage: 884 allocs, 831 frees, 2,083,975 bytes allocated ==13559== ==13559== Searching for pointers to 53 not-freed blocks ==13559== Checked 1,518,592 bytes ==13559== ==13559== LEAK SUMMARY: ==13559== definitely lost: 0 bytes in 0 blocks ==13559== indirectly lost: 0 bytes in 0 blocks ==13559== possibly lost: 0 bytes in 0 blocks ==13559== still reachable: 331,401 bytes in 53 blocks ==13559== suppressed: 0 bytes in 0 blocks ==13559== Reachable blocks (those to which a pointer was found) are not shown. ==13559== To see them, rerun with: --leak-check=full --show-reachable=yes ==13559== ==13559== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 4) --13559-- --13559-- used_suppression: 6 U1004-ARM-_dl_relocate_object ==13559== ==13559== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 4) There is no memory leak and I/O error , so set bug status to VERIFIED
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. http://rhn.redhat.com/errata/RHBA-2011-1513.html