All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Pan Nengyuan <pannengyuan@huawei.com>
Cc: zhang.zhanghailiang@huawei.com, euler.robot@huawei.com,
	dgilbert@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 1/2] migration/multifd: fix memleaks in multifd_new_send_channel_async
Date: Wed, 06 May 2020 10:42:27 +0200	[thread overview]
Message-ID: <874kstjvyk.fsf@secure.mitica> (raw)
In-Reply-To: <20200506095416.26099-2-pannengyuan@huawei.com> (Pan Nengyuan's message of "Wed, 6 May 2020 05:54:15 -0400")

Pan Nengyuan <pannengyuan@huawei.com> wrote:
> When error happen in multifd_new_send_channel_async, 'sioc' will not be used
> to create the multifd_send_thread. Let's free it to avoid a memleak. And also
> do error_free after migrate_set_error() to avoid another leak in the same place.
>
> The leak stack:
> Direct leak of 2880 byte(s) in 8 object(s) allocated from:
>     #0 0x7f20b5118ae8 in __interceptor_malloc (/lib64/libasan.so.5+0xefae8)
>     #1 0x7f20b44df1d5 in g_malloc (/lib64/libglib-2.0.so.0+0x531d5)
>     #2 0x564133bce18b in object_new_with_type /mnt/sdb/backup/qemu/qom/object.c:683
>     #3 0x564133eea950 in qio_channel_socket_new /mnt/sdb/backup/qemu/io/channel-socket.c:56
>     #4 0x5641339cfe4f in socket_send_channel_create /mnt/sdb/backup/qemu/migration/socket.c:37
>     #5 0x564133a10328 in multifd_save_setup /mnt/sdb/backup/qemu/migration/multifd.c:772
>     #6 0x5641339cebed in migrate_fd_connect /mnt/sdb/backup/qemu/migration/migration.c:3530
>     #7 0x5641339d15e4 in migration_channel_connect /mnt/sdb/backup/qemu/migration/channel.c:92
>     #8 0x5641339cf5b7 in socket_outgoing_migration /mnt/sdb/backup/qemu/migration/socket.c:108
>
> Direct leak of 384 byte(s) in 8 object(s) allocated from:
>     #0 0x7f20b5118cf0 in calloc (/lib64/libasan.so.5+0xefcf0)
>     #1 0x7f20b44df22d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5322d)
>     #2 0x56413406fc17 in error_setv /mnt/sdb/backup/qemu/util/error.c:61
>     #3 0x564134070464 in error_setg_errno_internal /mnt/sdb/backup/qemu/util/error.c:109
>     #4 0x5641340851be in inet_connect_addr /mnt/sdb/backup/qemu/util/qemu-sockets.c:379
>     #5 0x5641340851be in inet_connect_saddr /mnt/sdb/backup/qemu/util/qemu-sockets.c:458
>     #6 0x5641340870ab in socket_connect /mnt/sdb/backup/qemu/util/qemu-sockets.c:1105
>     #7 0x564133eeaabf in qio_channel_socket_connect_sync /mnt/sdb/backup/qemu/io/channel-socket.c:145
>     #8 0x564133eeabf5 in qio_channel_socket_connect_worker /mnt/sdb/backup/qemu/io/channel-socket.c:168
>
> Indirect leak of 360 byte(s) in 8 object(s) allocated from:
>     #0 0x7f20b5118ae8 in __interceptor_malloc (/lib64/libasan.so.5+0xefae8)
>     #1 0x7f20af901817 in __GI___vasprintf_chk (/lib64/libc.so.6+0x10d817)
>     #2 0x7f20b451fa6c in g_vasprintf (/lib64/libglib-2.0.so.0+0x93a6c)
>     #3 0x7f20b44f8cd0 in g_strdup_vprintf (/lib64/libglib-2.0.so.0+0x6ccd0)
>     #4 0x7f20b44f8d8c in g_strdup_printf (/lib64/libglib-2.0.so.0+0x6cd8c)
>     #5 0x56413406fc86 in error_setv /mnt/sdb/backup/qemu/util/error.c:65
>     #6 0x564134070464 in error_setg_errno_internal /mnt/sdb/backup/qemu/util/error.c:109
>     #7 0x5641340851be in inet_connect_addr /mnt/sdb/backup/qemu/util/qemu-sockets.c:379
>     #8 0x5641340851be in inet_connect_saddr /mnt/sdb/backup/qemu/util/qemu-sockets.c:458
>     #9 0x5641340870ab in socket_connect /mnt/sdb/backup/qemu/util/qemu-sockets.c:1105
>     #10 0x564133eeaabf in qio_channel_socket_connect_sync /mnt/sdb/backup/qemu/io/channel-socket.c:145
>     #11 0x564133eeabf5 in qio_channel_socket_connect_worker /mnt/sdb/backup/qemu/io/channel-socket.c:168
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

I am not sure that this are the only possible error cases, but they are
a step on the right direction.

Thanks, Juan.



  reply	other threads:[~2020-05-06  8:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06  9:54 [PATCH 0/2] migration/multifd: fix two memleaks Pan Nengyuan
2020-05-06  9:54 ` [PATCH 1/2] migration/multifd: fix memleaks in multifd_new_send_channel_async Pan Nengyuan
2020-05-06  8:42   ` Juan Quintela [this message]
2020-05-06  9:54 ` [PATCH 2/2] migration/multifd: Do error_free after migrate_set_error to avoid memleaks Pan Nengyuan
2020-05-06  8:43   ` Juan Quintela
2020-05-07 15:55 ` [PATCH 0/2] migration/multifd: fix two memleaks Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kstjvyk.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=euler.robot@huawei.com \
    --cc=pannengyuan@huawei.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhang.zhanghailiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.