From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] tests/9pfs: Use g_autofree and g_autoptr where possible
Date: Mon, 31 Jan 2022 08:35:24 +0100 [thread overview]
Message-ID: <20220131083524.4a5d5a8d@bahia> (raw)
In-Reply-To: <4981516.0zRxyBk1fS@silver>
On Sat, 29 Jan 2022 13:33:59 +0100
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> On Freitag, 28. Januar 2022 12:49:58 CET Christian Schoenebeck wrote:
> > On Mittwoch, 26. Januar 2022 18:11:36 CET Greg Kurz wrote:
> > > The template pointer in virtio_9p_create_local_test_dir() is leaked.
> > > Add the g_autofree annotation to fix that. While here, convert the
> > > rest of the virtio 9p test code to using g_autofree or g_autoptr
> > > where possible, since this is the preferred approach to avoid potential
> > > leaks in the future.
> > >
> > > Based-on:
> > > <f6602123c6f7d0d593466231b04fba087817abbd.1642879848.git.qemu_oss@crudebyt
> > > e
> > > .com> Signed-off-by: Greg Kurz <groug@kaod.org>
> > > ---
> > >
> > > tests/qtest/libqos/virtio-9p.c | 15 +++++----------
> > > 1 file changed, 5 insertions(+), 10 deletions(-)
> >
> > I fear there is something wrong with this patch:
> >
> > # Start of local tests
> > # starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest
> > unix:/tmp/qtest-4234.sock -qtest-log /dev/null -chardev
> > socket,path=/tmp/qtest-4234.qmp,id=char0 -mon chardev=char0,mode=control
> > -display none -M pc -fsdev
> > local,id=fsdev0,path='',security_model=mapped-xattr -device
> > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
> > qemu-system-x86_64: -device
> > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest: cannot initialize
> > fsdev 'fsdev0': failed to open '': No such file or directory Broken pipe
> > Aborted
>
> Reason ...
>
> > > diff --git a/tests/qtest/libqos/virtio-9p.c
> > > b/tests/qtest/libqos/virtio-9p.c index ef96ef006adc..0a0d0d16709b 100644
> > > --- a/tests/qtest/libqos/virtio-9p.c
> > > +++ b/tests/qtest/libqos/virtio-9p.c
> > > @@ -40,14 +40,13 @@ static char *concat_path(const char* a, const char* b)
> > >
> > > void virtio_9p_create_local_test_dir(void)
> > > {
> > >
> > > struct stat st;
> > >
> > > - char *pwd = g_get_current_dir();
> > > - char *template = concat_path(pwd, "qtest-9p-local-XXXXXX");
> > > + g_autofree char *pwd = g_get_current_dir();
> > > + g_autofree char *template = concat_path(pwd,
> > > "qtest-9p-local-XXXXXX");
> > >
> > > local_test_path = mkdtemp(template);
>
> ... mkdtemp() does not allocate a new buffer, it just modifies the character
> array passed, i.e. the address returned by mkdtemp() equals the address of
> variable 'template', and when virtio_9p_create_local_test_dir() scope is left,
> the global variable 'local_test_path' would then point to freed memory.
>
I hate global variables ;-) and the 'Returned result must be freed' comment
in 'concat_path()' is slightly misleading in this respect.
> I would drop g_autofree from template:
>
> char *template = concat_path(pwd, "qtest-9p-local-XXXXXX");
>
> And if it helps to silence a leak warning (haven't tested), to prepend
> g_autofree to the global variable instead:
>
> static g_autofree char *local_test_path;
>
The way to go is either drop the g_autofree annotation as you're
suggesting, but this would make the comment in 'concat_path()'
even more awkward, or go forward with the glib way and use
g_steal_pointer() which maps exactly to what the code is doing.
> Best regards,
> Christian Schoenebeck
>
>
next prev parent reply other threads:[~2022-01-31 7:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 17:11 [PATCH] tests/9pfs: Use g_autofree and g_autoptr where possible Greg Kurz
2022-01-27 7:57 ` Thomas Huth
2022-01-28 11:49 ` Christian Schoenebeck
2022-01-29 12:33 ` Christian Schoenebeck
2022-01-31 7:35 ` Greg Kurz [this message]
2022-01-31 12:37 ` Christian Schoenebeck
2022-01-31 14:44 ` Greg Kurz
2022-01-31 15:12 ` Christian Schoenebeck
2022-01-31 16:09 ` Greg Kurz
2022-01-31 16:18 ` Christian Schoenebeck
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=20220131083524.4a5d5a8d@bahia \
--to=groug@kaod.org \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=thuth@redhat.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).