mem-pool: free objects from pools on mem_pools_fini()

When using a minimal gfapi application that only initializes a small
graph (sink, shard and meta xlators) the following memory leaks are
reported by Valgrind:

  HEAP SUMMARY:
      in use at exit: 322,976 bytes in 75 blocks
    total heap usage: 684 allocs, 609 frees, 2,092,116 bytes allocated

With this change, the mem-pools are cleaned up on calling of
mem_pools_fini() and the objects in the pool are free'd.

  HEAP SUMMARY:
      in use at exit: 315,265 bytes in 58 blocks
    total heap usage: 684 allocs, 626 frees, 2,092,079 bytes allocated

This information was gathered with `./run-xlator.sh features/shard` that
comes with `gfapi-load-volfile` from gluster-debug-tools.

While working on the free'ing of the per_thread_pool_list_t structures,
it became apparent that GF_CALLOC() in mem_get_pool_list() gets
redirected to a standard calloc() without prepending the Gluster
specific memory header. This is because mem_pools_init() gets called
before THIS->ctx is valid, so it is not possible to check if memory
accounting is enabled or not. Because of this, the GF_CALLOC() call in
mem_get_pool_list() has been replaced by CALLOC() to prevent potential
mismatches between the allocation/free'ing of per_thread_pool_list_t
structures.

Change-Id: Id6f558816f399b0c613d74df36deac2300b6dd98
BUG: 1470170
URL: https://github.com/gluster/gluster-debug-tools
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: https://review.gluster.org/17768
Smoke: Gluster Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
Reviewed-by: soumya k <skoduri@redhat.com>

0 files changed, 0 insertions, 0 deletions