Re: reclaiming memory at dlclose time

[Bruno Haible]

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