----- Original Message ----- > From: "Raghavendra Gowdappa" <rgowd...@redhat.com> > To: "Pranith Kumar Karampuri" <pkara...@redhat.com> > Cc: "Gluster Devel" <gluster-devel@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" <pkara...@redhat.com> > > To: "Raghavendra Gowdappa" <rgowd...@redhat.com> > > Cc: "Gluster Devel" <gluster-devel@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" <pkara...@redhat.com> > > >> To: "Gluster Devel" <gluster-devel@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@gluster.org > > >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel > > >> > > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
