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

[Krishnan Parthasarathi]

----- Original Message -----
> On Thu, 18 Sep 2014 12:33:49 -0400 (EDT)
> Krishnan Parthasarathi <kparthas at redhat.com> wrote:
> 
> > I am going to be bold and throw a suggestion inspired from
> > what I read today. I was reading briefly about how kernel
> > manages its objects using the kobject data structure and
> > establishe 'liveness' (in the garbage collection sense)
> > relationship across objects. It allows one to group objects
> > into 'sets'. This would help us to categorise objects into
> > 'groups' and derive from statedumps which group the leaking
> > object belongs to and infer some context out of that. This is
> > different from the other approaches that have been discussde. I am not
> > familiar
> > with what more could be done with that sort of an infrastructure. I hope
> > this opens up the discussion and doesn't distract it.
> 
> Interesting thought.  What's the concept with this we'd implement
> for GlusterFS?
> 
>   eg what are the important points you reckon we should do, and
>      where would be the right places to start? :)

I was hoping someone in this list with Linux Kernel programming experience
would evaluate the merit in this idea :-) I would need some time to explore
more on this thought and share my proposal here. But before I sign-off on that note,
let me share what I was thinking when I wrote this.

In kernel, (almost) all types have an embedded kobject type in them. This kobject structure
embeds in it the interface and 'metadata' [sic] for managing the life cycle of the holding type.
This allows the kernel to keep the code that manages the life cycle separate from the actual type.
This can be loosely termed as polymorphic. 

In GlusterFS, we use the slab allocator technique to manage data types that are
expected to be allocated in large numbers over time. The 'metadata' pertaining to
which slab an object was allocated, resides 'outside' (just preceding) the memory area
of the object. This by itself is not bad, but turns out to be inconvenient to verify
if the 'metadata' is intact, while using gdb.

I think using kobject like approach in place of the current way of storing 'metadata'
for objects allocated in slab would make inspecting this 'metadata' more convenient.
An interesting side effect of imitating the kernel's strategy is we can inherit their
time-worn techniques for debugging memory management issues for free.

I hope this provokes further discussion ;)
 
~KP


> My personal twitter: twitter.com/realjustinclift
>