[Bug libstdc++/65434] Memory leak in pool constructor

emil.styrke at gmail dot com gcc-bugzilla@gcc.gnu.org
Tue Jan 26 13:51:00 GMT 2016


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434

Emil Styrke <emil.styrke at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |emil.styrke at gmail dot com

--- Comment #4 from Emil Styrke <emil.styrke at gmail dot com> ---
I just discovered that this will become a real leak if dlopen/dlclose:ing a
library that has been statically linked to libstdc++.  Each time the library is
opened a new pool object is created, and after dlclose it will not have any
references left. Valgrind shows this (after looping the dlopen/dlsym/dlclose
part a few times):

==3679== 3,707,904 bytes in 51 blocks are definitely lost in loss record 106 of
106
==3679==    at 0x4C2BBCF: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3679==    by 0x77335EF: _GLOBAL__sub_I_eh_alloc.cc (in
[...]/libmock_di_plugin.so)
==3679==    by 0x40105B9: call_init.part.0 (dl-init.c:72)
==3679==    by 0x40106CA: call_init (dl-init.c:30)
==3679==    by 0x40106CA: _dl_init (dl-init.c:120)
==3679==    by 0x4015586: dl_open_worker (dl-open.c:579)
==3679==    by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==    by 0x40149A2: _dl_open (dl-open.c:663)
==3679==    by 0x6B94FC8: dlopen_doit (dlopen.c:66)
==3679==    by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==    by 0x6B9562C: _dlerror_run (dlerror.c:163)
==3679==    by 0x6B95060: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==3679==    by 0x4F303E6: load_library (dipluginhandlerimpl.cpp:60)

I'm not sure if anything could be done about this, but it might be prudent to
add a warning to the documentation for -lstatic-libstdc++ explaining this.


More information about the Gcc-bugs mailing list