qemu-stable
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]