Hi all.
I'm trying hard to diagnose memory leaks in libgfapi access.
gluster 3.7.8
For this purpose, i've created simplest C code (basically only calling
glfs_new() and glfs_fini() ):
<file>
#include <glusterfs/api/glfs.h>
int main (int argc, char** argv) {
glfs_t *fs = NULL;
fs = glfs_new ("pool");
glfs_fini (fs);
return 0;
}
<file/>
CFLAGS="-O0 -g -pipe -fomit-frame-pointer -fpeel-loops"
CXXFLAGS="${CFLAGS}"
# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.9.3/work/gcc-4.9.3/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls
--without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.3
p1.4, pie-0.6.4' --enable-libstdcxx-time --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp
--disable-libcilkrts --enable-lto --with-cloog
--disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 4.9.3 (Gentoo 4.9.3 p1.4, pie-0.6.4)
# gcc hellogluster.c -lgfapi
I've patched (client) with:
http://review.gluster.org/#/c/13456/
http://review.gluster.org/#/c/13125/
http://review.gluster.org/#/c/13096/
Latest patchset versions.
Still leaks...
running valgrind on this code, produces:
# valgrind --leak-check=full --show-reachable=yes ./a.out
==20881== Memcheck, a memory error detector
==20881== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==20881== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==20881== Command: ./a.out
==20881==
==20881==
==20881== HEAP SUMMARY:
==20881== in use at exit: 35,938 bytes in 10 blocks
==20881== total heap usage: 94 allocs, 84 frees, 9,048,615 bytes allocated
==20881==
==20881== 8 bytes in 1 blocks are still reachable in loss record 1 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x5A8A806: __gf_default_calloc (mem-pool.h:118)
==20881== by 0x5A8A806: __glusterfs_this_location (globals.c:141)
==20881== by 0x4E3D1F4: glfs_new@@GFAPI_3.4.0 (glfs.c:650)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 82 bytes in 1 blocks are definitely lost in loss record 2 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x5A862D9: __gf_calloc (mem-pool.c:117)
==20881== by 0x5A54224: gf_strdup (mem-pool.h:185)
==20881== by 0x5A54224: gf_log_init (logging.c:736)
==20881== by 0x4E3D7D1: glfs_set_logging@@GFAPI_3.4.0 (glfs.c:786)
==20881== by 0x4E3D429: glfs_new@@GFAPI_3.4.0 (glfs.c:665)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 240 bytes in 1 blocks are definitely lost in loss record 3 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x5A862D9: __gf_calloc (mem-pool.c:117)
==20881== by 0x5A733D2: gf_timer_registry_init (timer.c:244)
==20881== by 0x5A734A6: gf_timer_call_after (timer.c:52)
==20881== by 0x5A557B2: __gf_log_inject_timer_event (logging.c:1791)
==20881== by 0x5A557B2: gf_log_inject_timer_event (logging.c:1813)
==20881== by 0x4E3D7F8: glfs_set_logging@@GFAPI_3.4.0 (glfs.c:790)
==20881== by 0x4E3D429: glfs_new@@GFAPI_3.4.0 (glfs.c:665)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 280 bytes in 1 blocks are definitely lost in loss record 4 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x5A862D9: __gf_calloc (mem-pool.c:117)
==20881== by 0x5A88A6A: iobuf_create_stdalloc_arena (iobuf.c:367)
==20881== by 0x5A88A6A: iobuf_pool_new (iobuf.c:431)
==20881== by 0x4E3D257: glusterfs_ctx_defaults_init (glfs.c:95)
==20881== by 0x4E3D257: glfs_new@@GFAPI_3.4.0 (glfs.c:659)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 288 bytes in 1 blocks are possibly lost in loss record 5 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x4011741: allocate_dtv (in /lib64/ld-2.21.so)
==20881== by 0x401206D: _dl_allocate_tls (in /lib64/ld-2.21.so)
==20881== by 0x5F0BD4C: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.21.so)
==20881== by 0x5A71E53: gf_thread_create (common-utils.c:3342)
==20881== by 0x5A7341B: gf_timer_registry_init (timer.c:256)
==20881== by 0x5A734A6: gf_timer_call_after (timer.c:52)
==20881== by 0x5A557B2: __gf_log_inject_timer_event (logging.c:1791)
==20881== by 0x5A557B2: gf_log_inject_timer_event (logging.c:1813)
==20881== by 0x4E3D7F8: glfs_set_logging@@GFAPI_3.4.0 (glfs.c:790)
==20881== by 0x4E3D429: glfs_new@@GFAPI_3.4.0 (glfs.c:665)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 576 bytes in 2 blocks are possibly lost in loss record 6 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x4011741: allocate_dtv (in /lib64/ld-2.21.so)
==20881== by 0x401206D: _dl_allocate_tls (in /lib64/ld-2.21.so)
==20881== by 0x5F0BD4C: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.21.so)
==20881== by 0x5A71E53: gf_thread_create (common-utils.c:3342)
==20881== by 0x5A982A1: syncenv_new (syncop.c:831)
==20881== by 0x4E3D291: glusterfs_ctx_defaults_init (glfs.c:106)
==20881== by 0x4E3D291: glfs_new@@GFAPI_3.4.0 (glfs.c:659)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 6,096 bytes in 1 blocks are still reachable in loss record 7 of 9
==20881== at 0x4C29FE0: malloc (vg_replace_malloc.c:299)
==20881== by 0x5A524D0: __gf_default_malloc (mem-pool.h:106)
==20881== by 0x5A524D0: xlator_mem_acct_init (xlator.c:520)
==20881== by 0x4E3D22A: glusterfs_ctx_defaults_init (glfs.c:74)
==20881== by 0x4E3D22A: glfs_new@@GFAPI_3.4.0 (glfs.c:659)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 12,768 bytes in 1 blocks are definitely lost in loss record 8 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x5A862D9: __gf_calloc (mem-pool.c:117)
==20881== by 0x5AB4283: event_pool_new_epoll (event-epoll.c:247)
==20881== by 0x5A859C1: event_pool_new (event.c:41)
==20881== by 0x4E3D276: glusterfs_ctx_defaults_init (glfs.c:100)
==20881== by 0x4E3D276: glfs_new@@GFAPI_3.4.0 (glfs.c:659)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== 15,600 bytes in 1 blocks are possibly lost in loss record 9 of 9
==20881== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711)
==20881== by 0x5A862D9: __gf_calloc (mem-pool.c:117)
==20881== by 0x5A981EE: syncenv_new (syncop.c:812)
==20881== by 0x4E3D291: glusterfs_ctx_defaults_init (glfs.c:106)
==20881== by 0x4E3D291: glfs_new@@GFAPI_3.4.0 (glfs.c:659)
==20881== by 0x400746: main (in /root/gf-test2/a.out)
==20881==
==20881== LEAK SUMMARY:
==20881== definitely lost: 13,370 bytes in 4 blocks
==20881== indirectly lost: 0 bytes in 0 blocks
==20881== possibly lost: 16,464 bytes in 4 blocks
==20881== still reachable: 6,104 bytes in 2 blocks
==20881== suppressed: 0 bytes in 0 blocks
==20881==
==20881== For counts of detected and suppressed errors, rerun with: -v
==20881== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
So in seems, that glfs_fini() does not free all mem after glfs_new(),
even when there is nothing happening in betweeen.
Please help.
Best regards
Piotr Rybicki
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
