Hide Forgot
Description of problem: As summary, this bug is only used for tracing issue for libvirt-0.9.3-8.el6.x86_64, in fact, it's okay for libvirt upstream and libvirt-0.9.4-0rc1.el6.x86_64. 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.virsh vol-list --pool default 5.echo "test" > test.txt 6.ll -h test.txt (get length of file test.txt) 7.valgrind -v --leak-check=full virsh vol-upload --vol foo.img --file test.txt --pool default --offset 0 --length 5 Actual results: ==2765== 262,216 bytes in 1 blocks are definitely lost in loss record 21 of 23 ==2765== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==2765== by 0x4C72A4D: virAlloc (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4D0EA22: ??? (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4D0AFCF: ??? (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4CF640A: ??? (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4CC8B8B: virStreamSend (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4CD4CF7: virStreamSendAll (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4191AC: cmdVolUpload (virsh.c:8015) ==2765== by 0x410CC2: vshCommandRun (virsh.c:12758) ==2765== by 0x41F286: main (virsh.c:14110) ==2765== ==2765== 262,216 bytes in 1 blocks are definitely lost in loss record 22 of 23 ==2765== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==2765== by 0x4C72A4D: virAlloc (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4D0EA22: ??? (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4D0AFCF: ??? (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4CF6323: ??? (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4CC85AE: virStreamFinish (in /usr/lib64/libvirt.so.0.9.3) ==2765== by 0x4191D4: cmdVolUpload (virsh.c:8026) ==2765== by 0x410CC2: vshCommandRun (virsh.c:12758) ==2765== by 0x41F286: main (virsh.c:14110) ==2765== ==2765== LEAK SUMMARY: ==2765== definitely lost: 524,432 bytes in 2 blocks ==2765== indirectly lost: 0 bytes in 0 blocks ==2765== possibly lost: 0 bytes in 0 blocks ==2765== still reachable: 331,501 bytes in 61 blocks ==2765== suppressed: 0 bytes in 0 blocks Expected results: Fix these 2 memory leak. Additional info: I haven't found which commit fix this issue.
Osier, if you know which commit fixes this issue, please paste it in here. Thanks, Alex
(In reply to comment #0) > Actual results: > ==2765== 262,216 bytes in 1 blocks are definitely lost in loss record 21 of 23 > ==2765== at 0x4A04A28: calloc (vg_replace_malloc.c:467) > ==2765== by 0x4C72A4D: virAlloc (in /usr/lib64/libvirt.so.0.9.3) > ==2765== by 0x4D0EA22: ??? (in /usr/lib64/libvirt.so.0.9.3) > ==2765== by 0x4D0AFCF: ??? (in /usr/lib64/libvirt.so.0.9.3) Update actual results with debuginfo package: ==18995== 262,216 bytes in 1 blocks are definitely lost in loss record 21 of 23 ==18995== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==18995== by 0x3DF8C43A4D: virAlloc (memory.c:101) ==18995== by 0x3DF8CDFA42: virNetMessageNew (virnetmessage.c:39) ==18995== by 0x3DF8CDBFCF: virNetClientStreamSendPacket (virnetclientstream.c:331) ==18995== by 0x3DF8CC740A: remoteStreamSend (remote_driver.c:3207) ==18995== by 0x3DF8C99B8B: virStreamSend (libvirt.c:12966) ==18995== by 0x3DF8CA5CF7: virStreamSendAll (libvirt.c:13166) ==18995== by 0x4191AC: cmdVolUpload (virsh.c:8015) ==18995== by 0x410CC2: vshCommandRun (virsh.c:12758) ==18995== by 0x41F286: main (virsh.c:14110) ==18995== ==18995== 262,216 bytes in 1 blocks are definitely lost in loss record 22 of 23 ==18995== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==18995== by 0x3DF8C43A4D: virAlloc (memory.c:101) ==18995== by 0x3DF8CDFA42: virNetMessageNew (virnetmessage.c:39) ==18995== by 0x3DF8CDBFCF: virNetClientStreamSendPacket (virnetclientstream.c:331) ==18995== by 0x3DF8CC7323: remoteStreamFinish (remote_driver.c:3362) ==18995== by 0x3DF8C995AE: virStreamFinish (libvirt.c:13442) ==18995== by 0x4191D4: cmdVolUpload (virsh.c:8026) ==18995== by 0x410CC2: vshCommandRun (virsh.c:12758) ==18995== by 0x41F286: main (virsh.c:14110) ==18995== ==18995== LEAK SUMMARY: ==18995== definitely lost: 524,432 bytes in 2 blocks ==18995== indirectly lost: 0 bytes in 0 blocks ==18995== possibly lost: 0 bytes in 0 blocks ==18995== still reachable: 331,494 bytes in 61 blocks ==18995== suppressed: 0 bytes in 0 blocks
Fixed in commit 927dfcf693165f5b08efba0d031d4cc43e6f9c37 Author: Daniel P. Berrange <berrange> Date: Fri Jul 8 12:35:36 2011 +0100 Fix leak of 'msg' object in client stream code In one exit path we forgot to free the virNetMessage object causing a large memory leak for streams which send a lot of data. Some other paths were calling VIR_FREE directly instead of virNetMessageFree although this was (currently) harmless. * src/rpc/virnetclientstream.c: Fix leak of msg object * src/rpc/virnetclientprogram.c: Call virNetMessageFree instead of VIR_FREE
This issue has been fixed on rhel6.2(2.6.32-160.el6.x86_64) with libvirt-0.9.4-0rc2.el6.x86_64 and qemu-kvm-0.12.1.2-2.169.el6.x86_64, the following is actual test result by valgrind, so change the bug status to VERIFIED. Actual result: Detected in valgrind run: ==1643== ==1643== HEAP SUMMARY: ==1643== in use at exit: 331,494 bytes in 61 blocks ==1643== total heap usage: 1,150 allocs, 1,089 frees, 2,956,048 bytes allocated ==1643== ==1643== Searching for pointers to 61 not-freed blocks ==1643== Checked 1,518,744 bytes ==1643== ==1643== LEAK SUMMARY: ==1643== definitely lost: 0 bytes in 0 blocks ==1643== indirectly lost: 0 bytes in 0 blocks ==1643== possibly lost: 0 bytes in 0 blocks ==1643== still reachable: 331,494 bytes in 61 blocks
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