[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 12/13] vl: plumb keyval-based options into -readconfig
From: |
Peter Maydell |
Subject: |
Re: [PULL 12/13] vl: plumb keyval-based options into -readconfig |
Date: |
Tue, 29 Jun 2021 13:52:04 +0100 |
On Fri, 4 Jun 2021 at 16:23, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> Let -readconfig support parsing command line options into QDict or
> QemuOpts. This will be used to add back support for objects in
> -readconfig.
>
> Cc: Markus Armbruster <armbru@redhat.com>
> Cc: qemu-stable@nongnu.org
> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> Message-Id: <20210524105752.3318299-3-pbonzini@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hi; Coverity suspects a resource leak in this code (CID 1457455):
> +/*
> + * Parse non-QemuOpts config file groups, pass the rest to
> + * qemu_config_do_parse.
> + */
> +static void qemu_parse_config_group(const char *group, QDict *qdict,
> + void *opaque, Error **errp)
> +{
> + QObject *crumpled;
> + if (is_qemuopts_group(group)) {
> + qemu_config_do_parse(group, qdict, opaque, errp);
> + return;
> + }
> +
> + crumpled = qdict_crumple(qdict, errp);
It thinks qdict_crumple() allocates memory...
> + if (!crumpled) {
> + return;
> + }
> + if (qobject_type(crumpled) != QTYPE_QDICT) {
> + assert(qobject_type(crumpled) == QTYPE_QLIST);
> + error_setg(errp, "Lists cannot be at top level of a configuration
> section");
...but here we return without freeing/derefing it or keeping track
of the pointer anywhere...
> + return;
> + }
> + qemu_record_config_group(group, qobject_to(QDict, crumpled), false,
> errp);
...and here it thinks that qemu_record_config_group does not free or
keep a pointer to 'crumpled', though in this case I suspect it is wrong.
More general question: where should I look to find documentation on
what functions take 'ownership' of a reference-counted object?
I often find when trying to analyse Coverity reports like these that
I am just as confused as it is about whether a function really has
taken ownership of something or whether the caller kept ownership
and needed to deref it...
thanks
-- PMM