[Gluster-devel] how do you debug ref leaks?

[Raghavendra Gowdappa]

For eg., if a dictionary is not freed because of non-zero refcount, if there is an information on who has held these references would help to narrow down the code path or component.

----- Original Message -----
> From: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> To: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Thursday, September 18, 2014 10:05:18 AM
> Subject: Re: [Gluster-devel] how do you debug ref leaks?
> 
> 
> On 09/18/2014 09:59 AM, Raghavendra Gowdappa wrote:
> > One thing that would be helpful is "allocator" info for generic objects
> > like dict, inode, fd etc. That way we wouldn't have to sift through large
> > amount of code.
> Could you elaborate the idea please.
> 
> Pranith
> > ----- Original Message -----
> >> From: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> >> To: "Gluster Devel" <gluster-devel at gluster.org>
> >> Sent: Thursday, September 18, 2014 7:43:00 AM
> >> Subject: [Gluster-devel] how do you debug ref leaks?
> >>
> >> hi,
> >>       Till now the only method I used to find ref leaks effectively is to
> >> find what operation is causing ref leaks and read the code to find if
> >> there is a ref-leak somewhere. Valgrind doesn't solve this problem
> >> because it is reachable memory from inode-table etc. I am just wondering
> >> if there is an effective way anyone else knows of. Do you guys think we
> >> need a better mechanism of finding refleaks? At least which decreases
> >> the search space significantly i.e. xlator y, fop f etc? It would be
> >> better if we can come up with ways to integrate statedump and this infra
> >> just like we did for mem-accounting.
> >>
> >> One way I thought was to introduce new apis called
> >> xl_fop_dict/inode/fd_ref/unref (). Each xl keeps an array of num_fops
> >> per inode/dict/fd and increments/decrements accordingly. Dump this info
> >> on statedump.
> >>
> >> I myself am not completely sure about this idea. It requires all xlators
> >> to change.
> >>
> >> Any ideas?
> >>
> >> Pranith
> >> _______________________________________________
> >> Gluster-devel mailing list
> >> Gluster-devel at gluster.org
> >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
> >>
> 
>