From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Ying Fang <fangying1@huawei.com>
Cc: lcf.lichaofeng@huawei.com,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
qemu-devel@nongnu.org, zhouyibo3@huawei.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH] qmp: Fix memory leak in migrate_params_test_apply
Date: Tue, 3 Sep 2019 17:46:55 +0100 [thread overview]
Message-ID: <20190903164655.GP2744@work-vm> (raw)
In-Reply-To: <20190827080512.2417-1-fangying1@huawei.com>
* Ying Fang (fangying1@huawei.com) wrote:
> Address Sanitizer shows memory leak in migrate_params_test_apply
> migration/migration.c:1253 and the stack is as bellow:
>
> Direct leak of 45 byte(s) in 9 object(s) allocated from:
> #0 0xffffbd7fc1db in __interceptor_malloc (/lib64/libasan.so.4+0xd31db)
> #1 0xffffbd514163 in g_malloc (/lib64/libglib-2.0.so.0+0x57163)
> #2 0xffffbd52f43b in g_strdup (/lib64/libglib-2.0.so.0+0x7243b)
> #3 0xaaaadfa4d623 in migrate_params_test_apply migration/migration.c:1253
> #4 0xaaaadfa4d623 in qmp_migrate_set_parameters migration/migration.c:1422
> #5 0xaaaadfa963f3 in hmp_migrate_set_parameter monitor/hmp-cmds.c:1867
> #6 0xaaaadfa8afe3 in handle_hmp_command monitor/hmp.c:1082
> #7 0xaaaadf479c57 in qmp_human_monitor_command monitor/misc.c:140
> #8 0xaaaadfadf87b in qmp_marshal_human_monitor_command qapi/qapi-commands-misc.c:1024
> #9 0xaaaadfc7797b in do_qmp_dispatch qapi/qmp-dispatch.c:131
> #10 0xaaaadfc7797b in qmp_dispatch qapi/qmp-dispatch.c:174
> #11 0xaaaadfa84fff in monitor_qmp_dispatch monitor/qmp.c:120
> #12 0xaaaadfa85bbf in monitor_qmp_bh_dispatcher monitor/qmp.c:209
> #13 0xaaaadfd2228f in aio_bh_call util/async.c:89
> #14 0xaaaadfd2228f in aio_bh_poll util/async.c:117
> #15 0xaaaadfd29bc3 in aio_dispatch util/aio-posix.c:459
> #16 0xaaaadfd21ff7 in aio_ctx_dispatch util/async.c:260
> #17 0xffffbd50e2f7 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x512f7)
> #18 0xaaaadfd278d7 in glib_pollfds_poll util/main-loop.c:218
> #19 0xaaaadfd278d7 in os_host_main_loop_wait util/main-loop.c:241
> #20 0xaaaadfd278d7 in main_loop_wait util/main-loop.c:517
> #21 0xaaaadf67b5e7 in main_loop vl.c:1806
> #22 0xaaaadf15d453 in main vl.c:4488
>
> Cc: zhanghailiang <zhang.zhanghailiang@huawei.com>
> Signed-off-by: Ying Fang <fangying1@huawei.com>
> ---
> migration/migration.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 8b9f2fe30a..05e44ff7cc 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1250,11 +1250,17 @@ static void migrate_params_test_apply(MigrateSetParameters *params,
>
> if (params->has_tls_creds) {
> assert(params->tls_creds->type == QTYPE_QSTRING);
> + if (dest->tls_creds) {
> + g_free(dest->tls_creds);
> + }
> dest->tls_creds = g_strdup(params->tls_creds->u.s);
> }
>
> if (params->has_tls_hostname) {
> assert(params->tls_hostname->type == QTYPE_QSTRING);
> + if (dest->tls_hostname) {
> + g_free(dest->tls_hostname);
> + }
> dest->tls_hostname = g_strdup(params->tls_hostname->u.s);
> }
Thanks for reporting the leak, but I don't think this is the right fix:
In the call chain we have, qmp_migrate_set_parameters calls:
migrate_params_test_apply(params, &tmp);
tmp is a stack allocated variable that becomes the 'dest'
we see here. Then at the top of migrate_params_test_apply
we have:
*dest = migrate_get_current()->parameters;
so that's probably bad; that's a shallow copy, so dest->tls_authz
points to the same storage as the real current migration parameters.
whne the code does:
if (params->has_tls_creds) {
assert(params->tls_creds->type == QTYPE_QSTRING);
dest->tls_creds = g_strdup(params->tls_creds->u.s);
}
it's only changing the pointer in the 'tmp' not the main copy
because of migrate_params_check fails then the parameters get entirely
unchanged. So if you do a free on dest->tls_hostname you end up
freeing the real parameter that's still getting used, not the tmp.
So I think we need to:
a) change migrate_params_test_apply so that it returns a
MigrationParameters * rather than taking &tmp
b) Make migrate_params_test use QAPI_CLONE to clone instead of doing:
*dest = migrate_get_current()->parameters;
c) Then do a qapi_free_MigrateParameters in qmp_migrate_set_parameters
on both the true and false paths.
Does that make sense?
Dave
>
> --
> 2.19.1
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-09-03 17:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 8:05 [Qemu-devel] [PATCH] qmp: Fix memory leak in migrate_params_test_apply Ying Fang
2019-08-27 8:30 ` no-reply
2019-08-27 8:38 ` Li Qiang
2019-08-27 9:13 ` fangying
2019-09-03 16:46 ` Dr. David Alan Gilbert [this message]
2019-09-04 7:24 ` fangying
-- strict thread matches above, loose matches on Subject: below --
2019-08-27 11:16 Ying Fang
2019-08-28 7:58 ` Stefano Garzarella
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=20190903164655.GP2744@work-vm \
--to=dgilbert@redhat.com \
--cc=fangying1@huawei.com \
--cc=lcf.lichaofeng@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=zhang.zhanghailiang@huawei.com \
--cc=zhouyibo3@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.