Jeffrey Walton wrote: > The use case is incomplete. It does not cover libraries. > > Just ask the OpenJDK guys about libraries like Ncurses and OpenSSL. > They were discussing library problems on the OpenSSL mailing list in > the past. > > You see, the application will remain loaded, but Java (and other > languages like .Net) will load the shared objects multiple times as > functions are needed (and then unload the shared object when the call > is done). > > The subsequent accumulated memory leak eventually crashes the app or device.
What you describe here, is a slightly different topic: reclaiming memory from shared libraries (not programs), at dlclose time (not before exit). Yes, I confirm that libncurses (libterminfo) has data that it allocates, like a static initializer would do. Yes, if a program repeatedly dlopen()s, uses, and dlclose()s such a library, it will exhibit a memory leak. (Side question: why would anyone dlclose libncurses or libssl? Sounds wasteful.) Glibc itself has a number of resource-freeing hooks [1]. GCC allows programmers to mark functions with __attribute__((__destructor__)) [2]. Does glibc walk through these destructors during dlclose()? Bruno [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=include/libc-symbols.h;hb=HEAD#l245 [2] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
