Bug 975392 - libvirtd leaks iscsi portal string on iscsi pool start
libvirtd leaks iscsi portal string on iscsi pool start
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ján Tomko
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-18 07:03 EDT by Ján Tomko
Modified: 2013-11-21 04:03 EST (History)
7 users (show)

See Also:
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 04:03:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ján Tomko 2013-06-18 07:03:27 EDT
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.
Comment 1 Ján Tomko 2013-06-18 07:05:38 EDT
Fixed upstream by:
commit 413274f63b8f2da3b1a4adfdf1cbc0df7a0e0316
Author:     Ján Tomko <jtomko@redhat.com>
AuthorDate: 2013-05-06 14:36:23 +0200
Commit:     Ján Tomko <jtomko@redhat.com>
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
Comment 7 zhenfeng wang 2013-07-09 06:29:33 EDT
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)
Comment 8 Ján Tomko 2013-07-10 09:43:30 EDT
None of the leaks seem significant to me and yes, it should be present in libvirt-0.10.2-18.el6.x86_64.
Comment 9 zhenfeng wang 2013-07-10 22:33:30 EDT
According to the comment8,mark this bug verified
Comment 11 errata-xmlrpc 2013-11-21 04:03:08 EST
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

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