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

[Pranith Kumar Karampuri]

On 09/18/2014 03:13 PM, Niels de Vos wrote:
> On Thu, Sep 18, 2014 at 07:43:00AM +0530, 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?
>  From my understanding, you are looking for something like this addition:
>
>      struct _xlator {
>              ...
>              struct {
>                      int64_t inodes[GF_FOP_MAXVALUE - 1];
>                      int64_t fds[GF_FOP_MAXVALUE - 1];
>                      ...
>              } refs;
>              ...
>      };
Correct.
>
> inode_table_new(.., *xl) gets the xlator passed, so it can in-/decrease
> the xl->refs->inodes[_call_frame_t->op] on future inode_new(),
> inode_ref() and inode_unref() calls.
Not like this. We are going to provide apis like
xl_fop_inode_ref(inode_t*, xlator_t*, fop op)
xl_fop_inode_unref(inode_t*, xlator_t*, fop op) and so on for fd, dict.

xlator code has to change :-(. That is the problem.
>
> Some of the difficulties I see ATM, are:
> - how to get to the _call_frame_t->op
> - correctly accounting FOPs like OPEN/CLOSE
>
> Mainly just tossing the idea here, maybe I'm completely missing the
> point, or there are other issues why this would be an impossible
> solution.
>
> Cheers,
> Niels