Re: two potential memory leak place found on glusterfs 3.12.3

["Storage, Dev (Nokia - Global)" <dev.storage@xxxxxxxxx>]

HI,

 

I think I find another suspicious memory leak.

In function vasprintf, the memory is allocated by GF_ALLOC, but when free this memory, it is not by GF_FREE , instead, it is freed by FREE or free. This will make memory accounting not accurate, also will have some memory lost.

There are many log interfaces in logging.c

Anyone know why the memory is not freed by GF_FREE ?

I see following explanation from _gf_log_eh

/* Use FREE instead of GF_FREE since str2 was allocated by vasprintf */

but why ?

 

From: Atin Mukherjee [mailto:amukherj@xxxxxxxxxx]
Sent: Tuesday, February 27, 2018 10:37 AM
To: Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx>; Gaurav Yadav <gyadav@xxxxxxxxxx>
Cc: Storage, Dev (Nokia - Global) <dev.storage@xxxxxxxxx>; Csaba Henk <chenk@xxxxxxxxxx>; gluster-devel@xxxxxxxxxxx; Madappa, Kaushal <kmadappa@xxxxxxxxxx>
Subject: Re: two potential memory leak place found on glusterfs 3.12.3

 

+Gaurav

 

On Mon, Feb 26, 2018 at 2:02 PM, Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:

+glusterd devs

 

On Mon, Feb 26, 2018 at 1:41 PM, Storage, Dev (Nokia - Global) <dev.storage@xxxxxxxxx> wrote:

Hi glusterfs experts,

       Good day!

       During our recent test we found that after execute some glusterfs command, there are obvious memory leak found for glusterd process, when we compare statedump of glusterd process before and after command executions.

      

1>   Each time of command “gluster volume list” command there are some memory lost from section [mgmt/glusterd.management - usage-type gf_common_mt_char memusage] in glusterd statedump, after investigation, we found that

For __glusterd_handle_cli_list_volume , after glusterd_submit_reply, should free rsp.dict.dict_val.

 This needs to be looked at.

2>   Each time of command “gluster volume status <volume name>” command there are some memory lost from section mgmt/glusterd.management - usage-type gf_common_mt_strdup memusage in glusterd statedump, after investigation, we found that

For glusterd_mgmt_v3_unlock, before gf_timer_call_cancel, should free pointer “data” in mgmt_lock_timer->timer.

 

Gaurav is working on a patch where this has been already identified. So the analysis on point 2 seems to be correct.
 

 

Could you help to comment on the above two findings? Thanks!

 

 

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel