https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70806
Bug ID: 70806
Summary: Missing deallocation of exception handler emergency
pool breaks -static-libstdc++ with dlopen
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: emil.styrke at gmail dot com
Target Milestone: ---
There are multiple reports of benign "memory leaks" (still reachable bytes) in
eh_alloc.c, for example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434.
And even a request for a hook to manually deallocate this memory in valgrind
and similar tools:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945
However, my use case is slightly different: Firstly, I build dynamic libraries
with -static-libstdc++ to be able to run on systems with libstdc++ older than
on the build machine. Secondly, I load such libraries as plugins with
dlopen/dlclose. This works fine in GCC 4.9, but leaks memory in GCC 5.
Each time the library is dlopened 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)
Is there any solution to this, other than me manually calling
__gnu_cxx::__freeres (mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945) before calling dlclose?
