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. ----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Thursday, September 18, 2014 7:43:00 AM > Subject: 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@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel