[Bugs] [Bug 1126831] Memory leak in GlusterFs client

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1126831

Raghavendra G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rgowdapp at redhat.com



--- Comment #6 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Poornima G from comment #1)
> From the logs, it looks like, quick-read performance xlator is calling
> iobuf_free with NULL pointers, implies quick-read could be leaking iobufs as
> well.

Patch [1] adds check before unref. So, we no longer should see these messages.
Also, just the presence of these logs cannot prove quick-read is leaking
iobufs. The reason is, 

* quick-read prunes an inode even after data is cached and an qr_inode_prune
deletes the data from qr_inode.
* qr_readv calls qr_readv_cached if it finds qr_inode set in inode ctx. However
this is not a guarantee that data is present as a qr_inode_prune might be
called on this inode.
* qr_readv_cached used to (before [1]) unconditionally call
iobuf_unref/iobref_unref which resulted in the log messages. Note that no
iobuf/iobref is allocated in this codepath as there is no data in qr_inode.
Hence its not a leak.

However there is one leak of "content" allocated. See, the definition of
qr_content_update:

void
qr_content_update (xlator_t *this, qr_inode_t *qr_inode, void *data,
                   struct iatt *buf)
{
        qr_private_t      *priv = NULL;
           qr_inode_table_t  *table = NULL;

        priv = this->private;
        table = &priv->table;

    LOCK (&table->lock);
        {
                __qr_inode_prune (table, qr_inode);

        qr_inode->data = data;

As can be seen above qr_inode->data is unconditionally set. So, if there is a
data already present, "data" will leak. However, qr_lookup won't set
GF_CONTENT_KEY if a qr_inode is already set in inode ctx and hence there not
too many cases where we find file content in xdata in qr_lookup_cbk (which
calls this function). But if there are simultaneous parallel fresh lookups
(where qr_lookup happening on the same file, we'll have more than one lookup
response containing data. This in turn can result in qr_content_update invoked
on a qr_inode which already has a non-NULL data and can result in a leak.
Please note that this is a race that can be hit only with more than one
parallel fresh lookup on a file. So, this leak _MAY_ not amount to large
memory.

[1] http://review.gluster.org/10206

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ncnjb43S0N&a=cc_unsubscribe