qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] qom-qmp-cmds: fix two memleaks in qmp_object_add


From: Pan Nengyuan
Subject: Re: [PATCH] qom-qmp-cmds: fix two memleaks in qmp_object_add
Date: Mon, 9 Mar 2020 18:17:17 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2


On 3/9/2020 5:51 PM, Igor Mammedov wrote:
> On Mon, 9 Mar 2020 17:22:12 +0800
> Pan Nengyuan <address@hidden> wrote:
> 
>> 'type/id' forgot to free in qmp_object_add, this patch fix that.
>>
>> The leak stack:
>> Direct leak of 84 byte(s) in 6 object(s) allocated from:
>>     #0 0x7fe2a5ebf768 in __interceptor_malloc (/lib64/libasan.so.5+0xef768)
>>     #1 0x7fe2a5044445 in g_malloc (/lib64/libglib-2.0.so.0+0x52445)
>>     #2 0x7fe2a505dd92 in g_strdup (/lib64/libglib-2.0.so.0+0x6bd92)
>>     #3 0x56344954e692 in qmp_object_add 
>> /mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qmp-cmds.c:258
>>     #4 0x563449960f5a in do_qmp_dispatch 
>> /mnt/sdb/qemu-new/qemu_test/qemu/qapi/qmp-dispatch.c:132
>>     #5 0x563449960f5a in qmp_dispatch 
>> /mnt/sdb/qemu-new/qemu_test/qemu/qapi/qmp-dispatch.c:175
>>     #6 0x563449498a30 in monitor_qmp_dispatch 
>> /mnt/sdb/qemu-new/qemu_test/qemu/monitor/qmp.c:145
>>     #7 0x56344949a64f in monitor_qmp_bh_dispatcher 
>> /mnt/sdb/qemu-new/qemu_test/qemu/monitor/qmp.c:234
>>     #8 0x563449a92a3a in aio_bh_call 
>> /mnt/sdb/qemu-new/qemu_test/qemu/util/async.c:136
>>
>> Direct leak of 54 byte(s) in 6 object(s) allocated from:
>>     #0 0x7fe2a5ebf768 in __interceptor_malloc (/lib64/libasan.so.5+0xef768)
>>     #1 0x7fe2a5044445 in g_malloc (/lib64/libglib-2.0.so.0+0x52445)
>>     #2 0x7fe2a505dd92 in g_strdup (/lib64/libglib-2.0.so.0+0x6bd92)
>>     #3 0x56344954e6c4 in qmp_object_add 
>> /mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qmp-cmds.c:267
>>     #4 0x563449960f5a in do_qmp_dispatch 
>> /mnt/sdb/qemu-new/qemu_test/qemu/qapi/qmp-dispatch.c:132
>>     #5 0x563449960f5a in qmp_dispatch 
>> /mnt/sdb/qemu-new/qemu_test/qemu/qapi/qmp-dispatch.c:175
>>     #6 0x563449498a30 in monitor_qmp_dispatch 
>> /mnt/sdb/qemu-new/qemu_test/qemu/monitor/qmp.c:145
>>     #7 0x56344949a64f in monitor_qmp_bh_dispatcher 
>> /mnt/sdb/qemu-new/qemu_test/qemu/monitor/qmp.c:234
>>     #8 0x563449a92a3a in aio_bh_call 
>> /mnt/sdb/qemu-new/qemu_test/qemu/util/async.c:136
>>
>> Fixes: 5f07c4d60d091320186e7b0edaf9ed2cc16b2d1e
>> Reported-by: Euler Robot <address@hidden>
>> Signed-off-by: Pan Nengyuan <address@hidden>
>> ---
>>  qom/qom-qmp-cmds.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c
>> index 49db926fcc..ac59ba1aa8 100644
>> --- a/qom/qom-qmp-cmds.c
>> +++ b/qom/qom-qmp-cmds.c
>> @@ -247,8 +247,8 @@ void qmp_object_add(QDict *qdict, QObject **ret_data, 
>> Error **errp)
>>      QDict *pdict;
>>      Visitor *v;
>>      Object *obj;
>> -    const char *type;
>> -    const char *id;
>> +    g_autofree const char *type = NULL;
>> +    g_autofree const char *id = NULL;
> 
> not sure that's it's correct
> 
> qdict_get_try_str() returns the reference to a string within
> the QDict, so caller who provided qdict should take care of
> freeing it.
> 
>>  
>>      type = qdict_get_try_str(qdict, "qom-type");
>>      if (!type) {
> 

    type = qdict_get_try_str(qdict, "qom-type");
    if (!type) {
        error_setg(errp, QERR_MISSING_PARAMETER, "qom-type");
        return;
    } else {
        type = g_strdup(type);
        qdict_del(qdict, "qom-type");
    }

If type is not NULL, it will go to the else branch, type re-assign immediately.
And it's aslo in the scope, so the string within the QDict will not be freed.

> .
> 



reply via email to

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