Bug 762724 (GLUSTER-992) - memory leak in afr_sh_algo_diff
Summary: memory leak in afr_sh_algo_diff
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-992
Product: GlusterFS
Classification: Community
Component: replicate
Version: 3.0.4
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Pavan Vilas Sondur
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-11 09:19 UTC by Raghavendra Bhat
Modified: 2010-07-22 09:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Raghavendra Bhat 2010-06-11 06:28:15 UTC
this is observed in 3.0.5rc6.

Comment 1 Raghavendra Bhat 2010-06-11 09:19:30 UTC
There is a memory leak in afr_sh_algo_diff. This is the valgrind report showing the mem-leak


 1,536 bytes in 48 blocks are definitely lost in loss record 123 of 145
==4084==    at 0x4C2414B: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4084==    by 0x668AB3F: afr_sh_algo_diff (afr-self-heal-algorithm.c:1051)
==4084==    by 0x66753E7: afr_sh_data_sync_prepare (afr-self-heal-data.c:644)
==4084==    by 0x6675979: afr_sh_data_fix (afr-self-heal-data.c:758)
==4084==    by 0x6675C2D: afr_sh_data_fstat_cbk (afr-self-heal-data.c:829)
==4084==    by 0x6430A8B: client_fstat_cbk (client-protocol.c:4379)
==4084==    by 0x64379DB: protocol_client_interpret (client-protocol.c:6571)
==4084==    by 0x64386A1: protocol_client_pollin (client-protocol.c:6869)
==4084==    by 0x6438D15: notify (client-protocol.c:6988)
==4084==    by 0x4E422F9: xlator_notify (xlator.c:929)
==4084==    by 0x7F35256: socket_event_poll_in (socket.c:771)
==4084==    by 0x7F35550: socket_event_handler (socket.c:871)


in afr_sh_algo_diff function memory is allocated in this way:

 for (i = 0; i < priv->data_self_heal_window_size; i++) {
                sh_priv->loops[i]               = CALLOC (1, sizeof (*sh_priv->loops[i]));

                sh_priv->loops[i]->checksum     = CALLOC (priv->child_count,
                                                          MD5_DIGEST_LEN);
                sh_priv->loops[i]->write_needed = CALLOC (priv->child_count,
                                                          sizeof (*sh_priv->loops[i]->write_needed));
        }

        sh_diff_loop_driver (frame, this);

        return 0;
  sh_priv = sh->private;

        for (i = 0; i < priv->data_self_heal_window_size; i++) {
                if (sh_priv->loops[i]) {
                        if (sh_priv->loops[i]->write_needed)
                                FREE (sh_priv->loops[i]->write_needed);

                        if (sh_priv->loops[i]->checksum)
                                FREE (sh_priv->loops[i]->checksum);
                }
        }

        if (sh_priv) {
                if (sh_priv->loops)
                        FREE (sh_priv->loops);

                FREE (sh_priv);
        }


sh_priv->loops[i] is not freed thus causing a memory leak.


In sh_diff_loop_driver function it calls sh_diff_private_cleanup function which frees the sh_private structures in the following manner.

Comment 2 Anand Avati 2010-06-14 08:32:13 UTC
PATCH: http://patches.gluster.com/patch/3412 in release-3.0 (free sh_priv->loops to avoid memory leak)

Comment 3 Anand Avati 2010-07-22 05:55:57 UTC
PATCH: http://patches.gluster.com/patch/3840 in master (free sh_priv->loops[i] in afr-self-heal-algorithm.c to avoid memory leak)


Note You need to log in before you can comment on or make changes to this bug.