[Gluster-devel] libgfapi 3.7.8 still memory leak
Soumya Koduri
skoduri at redhat.com
Thu Feb 18 03:29:56 UTC 2016
Hi Piotr,
On 02/17/2016 08:20 PM, Piotr Rybicki wrote:
> 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.
>
yes. "glfs_fini()" takes care of cleaning up most of the memory
allocated but not all. The original patch [1] posted by Poornima
contains all the details. The things left out there are not straight
forward but may need some intrusive fixes. Hence it may take a while to
walk through code, understand and provide fixes.
Thanks,
Soumya
[1] http://review.gluster.org/#/c/7642/
> Please help.
>
> Best regards
> Piotr Rybicki
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
More information about the Gluster-devel
mailing list