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.
