From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>,
Pino Toscano <ptoscano@redhat.com>
Cc: qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v2] qapi: fix memory leak in QmpOutputVisitor
Date: Fri, 21 Oct 2016 17:10:43 -0500 [thread overview]
Message-ID: <32b6baf4-cd23-c277-4dfb-79922c710efe@redhat.com> (raw)
In-Reply-To: <57db07f2-daee-c494-5ca0-651b53bcc889@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4735 bytes --]
On 10/21/2016 04:32 PM, Eric Blake wrote:
> In fact, applying this patch regresses to the very state that f24582d
> tried to prevent. However, I'm unable to see a difference in valgrind
> on tests/test-qmp-output-visitor either with or without this patch,
> which sadly means our testsuite is not actually testing this scenario.
>
>>> Should this go into -stable?
>
> NACK.
>
> As mentioned in the v1 thread, the leak that Pino was seeing is fixed by
> http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg04023.html
> I don't think we don't want this patch.
And below is my hack to test-qmp-output-visitor, which shows (at least
under valgrind) that we don't want the patch. I should probably turn
that into a formal patch submission; but should I piggyback the existing
test or add a new one? With the patch omitted, valgrind is happy; with
the patch applied, I see:
/visitor/output/struct-errors: ==8458== Invalid read of size 8
==8458== at 0x175DC2: qobject_decref (qobject.h:81)
==8458== by 0x1767A5: qentry_destroy (qdict.c:413)
==8458== by 0x17690B: qdict_destroy_obj (qdict.c:451)
==8458== by 0x1784AB: qobject_destroy (qobject.c:29)
==8458== by 0x171927: qobject_decref (qobject.h:83)
==8458== by 0x1721B4: qmp_output_free (qmp-output-visitor.c:223)
==8458== by 0x16ED8E: visit_free (qapi-visit-core.c:34)
==8458== by 0x130F39: visitor_output_teardown
(test-qmp-output-visitor.c:44)
==8458== by 0x130FE1: visitor_reset (test-qmp-output-visitor.c:59)
==8458== by 0x1326EF: test_visitor_out_struct_errors
(test-qmp-output-visitor.c:283)
==8458== by 0x50A8940: ??? (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x50A8B0E: ??? (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== Address 0x8259db8 is 8 bytes inside a block of size 4,120 free'd
==8458== at 0x4C2CD5A: free (vg_replace_malloc.c:530)
==8458== by 0x5088F2D: g_free (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x176937: qdict_destroy_obj (qdict.c:456)
==8458== by 0x1784AB: qobject_destroy (qobject.c:29)
==8458== by 0x171927: qobject_decref (qobject.h:83)
==8458== by 0x1721B4: qmp_output_free (qmp-output-visitor.c:223)
==8458== by 0x16ED8E: visit_free (qapi-visit-core.c:34)
==8458== by 0x130F39: visitor_output_teardown
(test-qmp-output-visitor.c:44)
==8458== by 0x130FE1: visitor_reset (test-qmp-output-visitor.c:59)
==8458== by 0x1326EF: test_visitor_out_struct_errors
(test-qmp-output-visitor.c:283)
==8458== by 0x50A8940: ??? (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x50A8B0E: ??? (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== Block was alloc'd at
==8458== at 0x4C2DA60: calloc (vg_replace_malloc.c:711)
==8458== by 0x5088E70: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x175EAF: qdict_new (qdict.c:33)
==8458== by 0x171CAB: qmp_output_start_struct (qmp-output-visitor.c:108)
==8458== by 0x16EE4A: visit_start_struct (qapi-visit-core.c:47)
==8458== by 0x1326E3: test_visitor_out_struct_errors
(test-qmp-output-visitor.c:282)
==8458== by 0x50A8940: ??? (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x50A8B0E: ??? (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x50A8B0E: ??? (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x50A8D1D: g_test_run_suite (in
/usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x50A8D40: g_test_run (in /usr/lib64/libglib-2.0.so.0.4800.2)
==8458== by 0x134F8D: main (test-qmp-output-visitor.c:899)
diff --git i/tests/test-qmp-output-visitor.c
w/tests/test-qmp-output-visitor.c
index 5e926d3..f1b5591 100644
--- i/tests/test-qmp-output-visitor.c
+++ w/tests/test-qmp-output-visitor.c
@@ -265,18 +265,22 @@ static void
test_visitor_out_struct_errors(TestOutputVisitorData *data,
EnumOne bad_values[] = { ENUM_ONE__MAX, -1 };
UserDefOne u = {0};
UserDefOne *pu = &u;
- Error *err;
+ Error *err = NULL;
int i;
+ /* First check: error within struct is detected */
for (i = 0; i < ARRAY_SIZE(bad_values) ; i++) {
- err = NULL;
u.has_enum1 = true;
u.enum1 = bad_values[i];
visit_type_UserDefOne(data->ov, "unused", &pu, &err);
- g_assert(err);
- error_free(err);
+ error_free_or_abort(&err);
visitor_reset(data);
}
+
+ /* Second check: aborting visit early doesn't leak */
+ visit_start_struct(data->ov, NULL, NULL, 0, &error_abort);
+ visit_start_struct(data->ov, "nested", NULL, 0, &error_abort);
+ visitor_reset(data);
}
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2016-10-21 22:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 10:37 [Qemu-devel] [PATCH v2] qapi: fix memory leak in QmpOutputVisitor Pino Toscano
2016-10-21 14:01 ` Markus Armbruster
2016-10-21 15:39 ` Eric Blake
2016-10-21 21:32 ` Eric Blake
2016-10-21 22:10 ` Eric Blake [this message]
2016-10-24 6:56 ` Markus Armbruster
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=32b6baf4-cd23-c277-4dfb-79922c710efe@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=ptoscano@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).