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

[Raghavendra Gowdappa]

----- Original Message -----
> From: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Thursday, September 18, 2014 10:08:15 AM
> Subject: Re: [Gluster-devel] how do you debug ref leaks?
> 
> 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.

This solution might be rudimentary. However, someone who has worked on things like garbage collection can give better answers I think. This discussion also reminds me of Greenspun's tenth rule [1]

[1] http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

> 
> ----- 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
> > >>
> > 
> > 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>