* [PATCH] block/nbd: fix memory leak in nbd_open()
@ 2019-11-28 8:40 pannengyuan
2019-11-28 9:01 ` Stefano Garzarella
0 siblings, 1 reply; 5+ messages in thread
From: pannengyuan @ 2019-11-28 8:40 UTC (permalink / raw)
To: eblake, kwolf, mreitz
Cc: liyiting, zhang.zhanghailiang, qemu-block, PanNengyuan,
qemu-devel, kuhn.chenqun
From: PanNengyuan <pannengyuan@huawei.com>
In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to reproduce:
1. run qemu-iotests as follow and check the result with asan:
./check -raw 143
Following is the asan output backtrack:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f6295e7e015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
#2 0x56281dab4642 in qobject_input_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
#3 0x56281dab1a04 in visit_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
#4 0x56281dad1827 in visit_type_SocketAddress qapi/qapi-visit-sockets.c:386
#5 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#6 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#7 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Direct leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
#4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281dab41a3 in qobject_input_type_str_keyval /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
#4 0x56281dab2ee9 in visit_type_str /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
#5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members qapi/qapi-visit-sockets.c:141
#6 0x56281dad17b6 in visit_type_SocketAddress_members qapi/qapi-visit-sockets.c:366
#7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
#8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#9 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
---
block/nbd.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/block/nbd.c b/block/nbd.c
index 1239761..bc40a25 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
ret = nbd_client_connect(bs, errp);
if (ret < 0) {
+ object_unref(OBJECT(s->tlscreds));
+ qapi_free_SocketAddress(s->saddr);
+ g_free(s->export);
+ g_free(s->tlscredsid);
+ g_free(s->x_dirty_bitmap);
return ret;
}
/* successfully connected */
--
2.7.2.windows.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] block/nbd: fix memory leak in nbd_open()
2019-11-28 8:40 [PATCH] block/nbd: fix memory leak in nbd_open() pannengyuan
@ 2019-11-28 9:01 ` Stefano Garzarella
2019-11-28 10:32 ` pannengyuan
0 siblings, 1 reply; 5+ messages in thread
From: Stefano Garzarella @ 2019-11-28 9:01 UTC (permalink / raw)
To: pannengyuan
Cc: kwolf, liyiting, zhang.zhanghailiang, qemu-block, qemu-devel,
mreitz, kuhn.chenqun
On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:
Hi,
I don't know nbd code very well, the patch LGTM, but just a comment
below:
> From: PanNengyuan <pannengyuan@huawei.com>
>
> In currently implementation there will be a memory leak when
> nbd_client_connect() returns error status. Here is an easy way to reproduce:
>
> 1. run qemu-iotests as follow and check the result with asan:
> ./check -raw 143
>
> Following is the asan output backtrack:
> Direct leak of 40 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
> #1 0x7f6295e7e015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
> #2 0x56281dab4642 in qobject_input_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
> #3 0x56281dab1a04 in visit_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
> #4 0x56281dad1827 in visit_type_SocketAddress qapi/qapi-visit-sockets.c:386
> #5 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> #6 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> #7 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>
> Direct leak of 15 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
> #4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>
> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> #3 0x56281dab41a3 in qobject_input_type_str_keyval /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
> #4 0x56281dab2ee9 in visit_type_str /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members qapi/qapi-visit-sockets.c:141
> #6 0x56281dad17b6 in visit_type_SocketAddress_members qapi/qapi-visit-sockets.c:366
> #7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
> #8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> #9 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> #10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
> ---
> block/nbd.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/block/nbd.c b/block/nbd.c
> index 1239761..bc40a25 100644
> --- a/block/nbd.c
> +++ b/block/nbd.c
> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
>
> ret = nbd_client_connect(bs, errp);
> if (ret < 0) {
> + object_unref(OBJECT(s->tlscreds));
> + qapi_free_SocketAddress(s->saddr);
> + g_free(s->export);
> + g_free(s->tlscredsid);
> + g_free(s->x_dirty_bitmap);
Since with this patch we are doing these cleanups in 3 places (here,
nbd_close(), and nbd_process_options()), should be better to add a new
function to do these cleanups?
Maybe I'd create a series adding a patch before this one, implementing this
new function, and change this patch calling it.
Thanks,
Stefano
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] block/nbd: fix memory leak in nbd_open()
2019-11-28 9:01 ` Stefano Garzarella
@ 2019-11-28 10:32 ` pannengyuan
2019-11-28 10:41 ` Stefano Garzarella
0 siblings, 1 reply; 5+ messages in thread
From: pannengyuan @ 2019-11-28 10:32 UTC (permalink / raw)
To: Stefano Garzarella
Cc: kwolf, liyiting, zhang.zhanghailiang, qemu-block, qemu-devel,
mreitz, kuhn.chenqun
Hi,
I think it's a better way, you can implement this new function before
this patch.
Thanks.
On 2019/11/28 17:01, Stefano Garzarella wrote:
> On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:
>
> Hi,
> I don't know nbd code very well, the patch LGTM, but just a comment
> below:
>
>> From: PanNengyuan <pannengyuan@huawei.com>
>>
>> In currently implementation there will be a memory leak when
>> nbd_client_connect() returns error status. Here is an easy way to reproduce:
>>
>> 1. run qemu-iotests as follow and check the result with asan:
>> ./check -raw 143
>>
>> Following is the asan output backtrack:
>> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
>> #1 0x7f6295e7e015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
>> #2 0x56281dab4642 in qobject_input_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
>> #3 0x56281dab1a04 in visit_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
>> #4 0x56281dad1827 in visit_type_SocketAddress qapi/qapi-visit-sockets.c:386
>> #5 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>> #6 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>> #7 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Direct leak of 15 byte(s) in 1 object(s) allocated from:
>> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>> #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
>> #4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>> #3 0x56281dab41a3 in qobject_input_type_str_keyval /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
>> #4 0x56281dab2ee9 in visit_type_str /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
>> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members qapi/qapi-visit-sockets.c:141
>> #6 0x56281dad17b6 in visit_type_SocketAddress_members qapi/qapi-visit-sockets.c:366
>> #7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
>> #8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>> #9 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>> #10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Reported-by: Euler Robot <euler.robot@huawei.com>
>> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
>> ---
>> block/nbd.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/block/nbd.c b/block/nbd.c
>> index 1239761..bc40a25 100644
>> --- a/block/nbd.c
>> +++ b/block/nbd.c
>> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
>>
>> ret = nbd_client_connect(bs, errp);
>> if (ret < 0) {
>> + object_unref(OBJECT(s->tlscreds));
>> + qapi_free_SocketAddress(s->saddr);
>> + g_free(s->export);
>> + g_free(s->tlscredsid);
>> + g_free(s->x_dirty_bitmap);
>
> Since with this patch we are doing these cleanups in 3 places (here,
> nbd_close(), and nbd_process_options()), should be better to add a new
> function to do these cleanups?
>
> Maybe I'd create a series adding a patch before this one, implementing this
> new function, and change this patch calling it.
>
> Thanks,
> Stefano
>
>
> .
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] block/nbd: fix memory leak in nbd_open()
2019-11-28 10:32 ` pannengyuan
@ 2019-11-28 10:41 ` Stefano Garzarella
2019-11-28 10:49 ` pannengyuan
0 siblings, 1 reply; 5+ messages in thread
From: Stefano Garzarella @ 2019-11-28 10:41 UTC (permalink / raw)
To: pannengyuan
Cc: kwolf, liyiting, zhang.zhanghailiang, qemu-block, qemu-devel,
mreitz, kuhn.chenqun
On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote:
> Hi,
> I think it's a better way, you can implement this new function before
> this patch.
If you want to do it, so you can send everything together, for me there's
no problem, it was just a suggestion.
If you don't have time, I can do it.
Cheers,
Stefano
>
> Thanks.
>
> On 2019/11/28 17:01, Stefano Garzarella wrote:
> > On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:
> >
> > Hi,
> > I don't know nbd code very well, the patch LGTM, but just a comment
> > below:
> >
> >> From: PanNengyuan <pannengyuan@huawei.com>
> >>
> >> In currently implementation there will be a memory leak when
> >> nbd_client_connect() returns error status. Here is an easy way to reproduce:
> >>
> >> 1. run qemu-iotests as follow and check the result with asan:
> >> ./check -raw 143
> >>
> >> Following is the asan output backtrack:
> >> Direct leak of 40 byte(s) in 1 object(s) allocated from:
> >> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
> >> #1 0x7f6295e7e015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
> >> #2 0x56281dab4642 in qobject_input_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
> >> #3 0x56281dab1a04 in visit_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
> >> #4 0x56281dad1827 in visit_type_SocketAddress qapi/qapi-visit-sockets.c:386
> >> #5 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> >> #6 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> >> #7 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Direct leak of 15 byte(s) in 1 object(s) allocated from:
> >> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> >> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> >> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> >> #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
> >> #4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
> >> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> >> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> >> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> >> #3 0x56281dab41a3 in qobject_input_type_str_keyval /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
> >> #4 0x56281dab2ee9 in visit_type_str /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
> >> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members qapi/qapi-visit-sockets.c:141
> >> #6 0x56281dad17b6 in visit_type_SocketAddress_members qapi/qapi-visit-sockets.c:366
> >> #7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
> >> #8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> >> #9 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> >> #10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Reported-by: Euler Robot <euler.robot@huawei.com>
> >> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
> >> ---
> >> block/nbd.c | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/block/nbd.c b/block/nbd.c
> >> index 1239761..bc40a25 100644
> >> --- a/block/nbd.c
> >> +++ b/block/nbd.c
> >> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
> >>
> >> ret = nbd_client_connect(bs, errp);
> >> if (ret < 0) {
> >> + object_unref(OBJECT(s->tlscreds));
> >> + qapi_free_SocketAddress(s->saddr);
> >> + g_free(s->export);
> >> + g_free(s->tlscredsid);
> >> + g_free(s->x_dirty_bitmap);
> >
> > Since with this patch we are doing these cleanups in 3 places (here,
> > nbd_close(), and nbd_process_options()), should be better to add a new
> > function to do these cleanups?
> >
> > Maybe I'd create a series adding a patch before this one, implementing this
> > new function, and change this patch calling it.
> >
> > Thanks,
> > Stefano
> >
> >
> > .
> >
>
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] block/nbd: fix memory leak in nbd_open()
2019-11-28 10:41 ` Stefano Garzarella
@ 2019-11-28 10:49 ` pannengyuan
0 siblings, 0 replies; 5+ messages in thread
From: pannengyuan @ 2019-11-28 10:49 UTC (permalink / raw)
To: Stefano Garzarella
Cc: kwolf, liyiting, zhang.zhanghailiang, qemu-block, qemu-devel,
mreitz, kuhn.chenqun
Thanks for you suggestion, I'd be glad to do it, I will send a new
version later.
Cheers.
On 2019/11/28 18:41, Stefano Garzarella wrote:
> On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote:
>> Hi,
>> I think it's a better way, you can implement this new function before
>> this patch.
>
> If you want to do it, so you can send everything together, for me there's
> no problem, it was just a suggestion.
>
> If you don't have time, I can do it.
>
> Cheers,
> Stefano
>
>>
>> Thanks.
>>
>> On 2019/11/28 17:01, Stefano Garzarella wrote:
>>> On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:
>>>
>>> Hi,
>>> I don't know nbd code very well, the patch LGTM, but just a comment
>>> below:
>>>
>>>> From: PanNengyuan <pannengyuan@huawei.com>
>>>>
>>>> In currently implementation there will be a memory leak when
>>>> nbd_client_connect() returns error status. Here is an easy way to reproduce:
>>>>
>>>> 1. run qemu-iotests as follow and check the result with asan:
>>>> ./check -raw 143
>>>>
>>>> Following is the asan output backtrack:
>>>> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>>>> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
>>>> #1 0x7f6295e7e015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
>>>> #2 0x56281dab4642 in qobject_input_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
>>>> #3 0x56281dab1a04 in visit_start_struct /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
>>>> #4 0x56281dad1827 in visit_type_SocketAddress qapi/qapi-visit-sockets.c:386
>>>> #5 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>>>> #6 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>>>> #7 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>>>
>>>> Direct leak of 15 byte(s) in 1 object(s) allocated from:
>>>> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>>>> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>>>> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>>>> #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
>>>> #4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>>>
>>>> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>>>> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>>>> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>>>> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>>>> #3 0x56281dab41a3 in qobject_input_type_str_keyval /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
>>>> #4 0x56281dab2ee9 in visit_type_str /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
>>>> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members qapi/qapi-visit-sockets.c:141
>>>> #6 0x56281dad17b6 in visit_type_SocketAddress_members qapi/qapi-visit-sockets.c:366
>>>> #7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
>>>> #8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>>>> #9 0x56281da8062f in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>>>> #10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>>>
>>>> Reported-by: Euler Robot <euler.robot@huawei.com>
>>>> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
>>>> ---
>>>> block/nbd.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/block/nbd.c b/block/nbd.c
>>>> index 1239761..bc40a25 100644
>>>> --- a/block/nbd.c
>>>> +++ b/block/nbd.c
>>>> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
>>>>
>>>> ret = nbd_client_connect(bs, errp);
>>>> if (ret < 0) {
>>>> + object_unref(OBJECT(s->tlscreds));
>>>> + qapi_free_SocketAddress(s->saddr);
>>>> + g_free(s->export);
>>>> + g_free(s->tlscredsid);
>>>> + g_free(s->x_dirty_bitmap);
>>>
>>> Since with this patch we are doing these cleanups in 3 places (here,
>>> nbd_close(), and nbd_process_options()), should be better to add a new
>>> function to do these cleanups?
>>>
>>> Maybe I'd create a series adding a patch before this one, implementing this
>>> new function, and change this patch calling it.
>>>
>>> Thanks,
>>> Stefano
>>>
>>>
>>> .
>>>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-11-28 11:02 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-28 8:40 [PATCH] block/nbd: fix memory leak in nbd_open() pannengyuan
2019-11-28 9:01 ` Stefano Garzarella
2019-11-28 10:32 ` pannengyuan
2019-11-28 10:41 ` Stefano Garzarella
2019-11-28 10:49 ` pannengyuan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.