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

[Pranith Kumar Karampuri]

On 09/18/2014 07:48 PM, Shyam wrote:
> On 09/17/2014 10:13 PM, Pranith Kumar Karampuri wrote:
>> 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?
>
> On a debug build we can use backtrace information stashed per ref and 
> unref, this will give us history of refs taken and released. Which 
> will also give the code path where ref was taken and released.
>
> It is heavy weight, so not for non-debug setups, but if a problem is 
> reproducible this could be a quick way to check who is not releasing 
> the ref's or have a history of the refs and unrefs to dig better into 
> code.
>
Do you have any ideas for final builds also? Basically when users report 
leaks it should not take us too long to figure out the problem area. We 
should just ask them for statedump and should be able to figure out the 
problem.

Pranith
> Shyam
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel