core : free up mem_acct.rec in xlator_destroy

Problem:
We've observed that glusterd was OOM killed after some minutes when volume set
command was run in a loop.

Analysis:

Initially the suspection was in glusterd code, but a deep dive into the codebase
revealed that while validating all the options as part of graph reconfiguration
at the time of freeing up the xlator object its one of the member mem_acct is
left over which causes memory leak.

Solution:

Free up xlator's mem_acct.rec in xlator_destroy ()

Change-Id: Ie9e7267e1ac4ab7b8af6e4d7c6660dfe99b4d641
BUG: 1201203
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
Reviewed-on: http://review.gluster.org/9862
Reviewed-by: Niels de Vos <ndevos@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>

1 files changed, 20 insertions, 0 deletions

diff --git a/libglusterfs/src/xlator.c b/libglusterfs/src/xlator.c
index 00f411e275b..5b6a4b52e33 100644
--- a/libglusterfs/src/xlator.c
+++ b/libglusterfs/src/xlator.c
@@ -557,6 +557,25 @@ xlator_list_destroy (xlator_list_t *list)
 }
 
 static int
+xlator_memrec_free (xlator_t *xl)
+{
+        uint32_t i = 0;
+
+        if (!xl)
+                return 0;
+
+        if (xl->mem_acct.rec) {
+                for (i = 0; i < xl->mem_acct.num_types; i++) {
+                        LOCK_DESTROY (&(xl->mem_acct.rec[i].lock));
+                }
+                FREE (xl->mem_acct.rec);
+                xl->mem_acct.rec = NULL;
+        }
+
+        return 0;
+}
+
+static int
 xlator_members_free (xlator_t *xl)
 {
         volume_opt_list_t *vol_opt = NULL;
@@ -912,6 +931,7 @@ xlator_destroy (xlator_t *xl)
                 return 0;
 
         xlator_members_free (xl);
+        xlator_memrec_free (xl);
         GF_FREE (xl);
 
         return 0;