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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).