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

[Niels de Vos]

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;
            ...
    };

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.

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