Bug 975392
| Summary: | libvirtd leaks iscsi portal string on iscsi pool start | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ján Tomko <jtomko> |
| Component: | libvirt | Assignee: | Ján Tomko <jtomko> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.4 | CC: | acathrow, ajia, dyuan, jtomko, ydu, zhwang, zpeng |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-0.10.2-19.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-21 09:03:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Fixed upstream by:
commit 413274f63b8f2da3b1a4adfdf1cbc0df7a0e0316
Author: Ján Tomko <jtomko>
AuthorDate: 2013-05-06 14:36:23 +0200
Commit: Ján Tomko <jtomko>
CommitDate: 2013-05-09 14:25:11 +0200
iscsi: don't leak portal string when starting a pool
git describe: v1.0.5-109-g413274f contains: v1.0.6-rc1~277
Posted downstream:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-June/msg00308.html
Verify this bug on libvirt-0.10.2-19.el6,the leak described in the bug has gone, however I found that there was some possibly leak existing, do we have necessary to pay attention about them ? thanks 1. run libvirtd under valgrind # valgrind --leak-check=full libvirtd 2. Start an iscsi pool in another terminal # virsh pool-start iscsi Pool iscsi started 3.Quit the valgrind command (after two pool-start/pool-destroy cycles) ,I can got the following outputs in the first terminal 4481== 48 bytes in 2 blocks are possibly lost in loss record 635 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CCE615A0E: nl_addr_alloc (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE616157: nl_addr_build (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE620F8D: ??? (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61795B: nl_cache_parse (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61C181: nl_recvmsgs (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617CB5: __cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617E9B: nl_cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE620DE4: rtnl_addr_alloc_cache (in /lib64/libnl.so.1.1) ==4481== by 0x3CB9608442: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x3CB9606F9E: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x4F2548: interfaceOpenInterface (interface_backend_netcf.c:141) ==4481== ==4481== 104 bytes in 4 blocks are possibly lost in loss record 789 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CCE615A0E: nl_addr_alloc (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE616157: nl_addr_build (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE6249CD: ??? (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61795B: nl_cache_parse (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61C181: nl_recvmsgs (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617CB5: __cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617E9B: nl_cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE623C24: rtnl_link_alloc_cache (in /lib64/libnl.so.1.1) ==4481== by 0x3CB960842A: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x3CB9606F9E: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x4F2548: interfaceOpenInterface (interface_backend_netcf.c:141) ==4481== ==4481== 104 bytes in 4 blocks are possibly lost in loss record 790 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CCE615A0E: nl_addr_alloc (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE616157: nl_addr_build (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE624A05: ??? (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61795B: nl_cache_parse (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61C181: nl_recvmsgs (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617CB5: __cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617E9B: nl_cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE623C24: rtnl_link_alloc_cache (in /lib64/libnl.so.1.1) ==4481== by 0x3CB960842A: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x3CB9606F9E: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x4F2548: interfaceOpenInterface (interface_backend_netcf.c:141) ==4481== ==4481== 144 bytes in 5 blocks are possibly lost in loss record 871 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CCE615A0E: nl_addr_alloc (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE616157: nl_addr_build (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE620F32: ??? (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61795B: nl_cache_parse (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61C181: nl_recvmsgs (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617CB5: __cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617E9B: nl_cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE620DE4: rtnl_addr_alloc_cache (in /lib64/libnl.so.1.1) ==4481== by 0x3CB9608442: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x3CB9606F9E: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x4F2548: interfaceOpenInterface (interface_backend_netcf.c:141) ==4481== ==4481== 720 bytes in 5 blocks are possibly lost in loss record 1,141 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CCE61CEA0: nl_object_alloc (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE620E44: ??? (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61795B: nl_cache_parse (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61C181: nl_recvmsgs (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617CB5: __cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617E9B: nl_cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE620DE4: rtnl_addr_alloc_cache (in /lib64/libnl.so.1.1) ==4481== by 0x3CB9608442: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x3CB9606F9E: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x4F2548: interfaceOpenInterface (interface_backend_netcf.c:141) ==4481== by 0x4F0C6CC: do_open (libvirt.c:1212) ==4481== ==4481== 1,600 bytes in 4 blocks are possibly lost in loss record 1,200 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CCE61CEA0: nl_object_alloc (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE624817: ??? (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61795B: nl_cache_parse (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE61C181: nl_recvmsgs (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617CB5: __cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE617E9B: nl_cache_pickup (in /lib64/libnl.so.1.1) ==4481== by 0x3CCE623C24: rtnl_link_alloc_cache (in /lib64/libnl.so.1.1) ==4481== by 0x3CB960842A: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x3CB9606F9E: ??? (in /usr/lib64/libnetcf.so.1.4.0) ==4481== by 0x4F2548: interfaceOpenInterface (interface_backend_netcf.c:141) ==4481== by 0x4F0C6CC: do_open (libvirt.c:1212) ==4481== ==4481== 1,840 bytes in 5 blocks are possibly lost in loss record 1,205 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CB7E11812: _dl_allocate_tls (in /lib64/ld-2.12.so) ==4481== by 0x3CB8A07068: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.12.so) ==4481== by 0x4E7FF50: virThreadCreate (threads-pthread.c:188) ==4481== by 0x4E808B3: virThreadPoolNew (threadpool.c:203) ==4481== by 0x4F5E199: virNetServerNew (virnetserver.c:376) ==4481== by 0x423396: main (libvirtd.c:1088) ==4481== ==4481== 1,840 bytes in 5 blocks are possibly lost in loss record 1,206 of 1,316 ==4481== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==4481== by 0x3CB7E11812: _dl_allocate_tls (in /lib64/ld-2.12.so) ==4481== by 0x3CB8A07068: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.12.so) ==4481== by 0x4E7FF50: virThreadCreate (threads-pthread.c:188) ==4481== by 0x4E8099A: virThreadPoolNew (threadpool.c:227) ==4481== by 0x4F5E199: virNetServerNew (virnetserver.c:376) ==4481== by 0x423396: main (libvirtd.c:1088) Also I can reproduce this bug on libvirt-0.10.2-18.el6.x86_64 1.Quit the valgrind command (after two pool-start/pool-destroy cycles) ,I can got the following outputs 40 bytes in 2 blocks are definitely lost in loss record 401 of 685 ==4845== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==4845== by 0x3CB8701EF7: __vasprintf_chk (in /lib64/libc-2.12.so) ==4845== by 0x4E81EB3: virVasprintf (stdio2.h:199) ==4845== by 0x4E81F57: virAsprintf (util.c:2001) ==4845== by 0x4E2AC9: virStorageBackendISCSIPortal (storage_backend_iscsi.c:109) ==4845== by 0x4E2CEC: virStorageBackendISCSIStartPool (storage_backend_iscsi.c:718) ==4845== by 0x4D67F8: storagePoolStart (storage_driver.c:702) ==4845== by 0x4EFA757: virStoragePoolCreate (libvirt.c:12466) ==4845== by 0x439544: remoteDispatchStoragePoolCreateHelper (remote_dispatch.h:11561) ==4845== by 0x4F5C161: virNetServerProgramDispatch (virnetserverprogram.c:431) ==4845== by 0x4F5CDFD: virNetServerProcessMsg (virnetserver.c:170) ==4845== by 0x4F5D49B: virNetServerHandleJob (virnetserver.c:191) None of the leaks seem significant to me and yes, it should be present in libvirt-0.10.2-18.el6.x86_64. 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-2013-1581.html |
Description of problem: libvirtd leaks iscsi portal string on iscsi pool start, as shown by valgrind. Version-Release number of selected component (if applicable): libvirt-0.10.2-18.el6.x86_64 How reproducible: 100 % Steps to Reproduce: 1. run libvirtd under valgrind # valgrind --leak-check=full libvirtd 2. Start an iscsi pool: # virsh pool-dumpxml iscsi <pool type='iscsi'> <name>iscsi</name> <uuid>86ba4417-8db7-493b-a61a-c56fb3128333</uuid> <capacity unit='bytes'>0</capacity> <allocation unit='bytes'>0</allocation> <available unit='bytes'>0</available> <source> <host name='10.11.12.13'/> <device path='iqn.2004-04.fedora:fedora13:iscsi.test'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0755</mode> <owner>-1</owner> <group>-1</group> </permissions> </target> </pool> # virsh pool-start iscsi Pool iscsi started Actual results (after two pool-start/pool-destroy cycles): Valgrind shows a memory leak in virStorageBackendISCSIStartPool: ==4289== 40 bytes in 2 blocks are definitely lost in loss record 380 of 649 ==4289== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==4289== by 0x3AED701EF7: __vasprintf_chk (vasprintf_chk.c:82) ==4289== by 0x31A4C64EB3: virVasprintf (stdio2.h:199) ==4289== by 0x31A4C64F57: virAsprintf (util.c:2001) ==4289== by 0x4E2AC9: virStorageBackendISCSIPortal (storage_backend_iscsi.c:109) ==4289== by 0x4E2CEC: virStorageBackendISCSIStartPool (storage_backend_iscsi.c:718) ==4289== by 0x4D67F8: storagePoolStart (storage_driver.c:702) ==4289== by 0x31A4CDD757: virStoragePoolCreate (libvirt.c:12466) ==4289== by 0x439544: remoteDispatchStoragePoolCreateHelper (remote_dispatch.h:11561) ==4289== by 0x31A4D3F161: virNetServerProgramDispatch (virnetserverprogram.c:431) ==4289== by 0x31A4D3FDFD: virNetServerProcessMsg (virnetserver.c:170) ==4289== by 0x31A4D4049B: virNetServerHandleJob (virnetserver.c:191) Expected results: It doesn't.