Pan Nengyuan <pannengy...@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.ro...@huawei.com> > Signed-off-by: Pan Nengyuan <pannengy...@huawei.com>
Reviewed-by: Juan Quintela <quint...@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.
