Why Did Dlclose Not Unload the Library? (2023)
Key topics
The mystery of why `dlclose` didn't unload a library sparked a lively debate, with commenters weighing in on the complexities of dynamic library management. Some pointed out that `dlclose` can't simply unload a library without checking its dependencies, which can lead to a cascade of reference counting and potential resource leaks. A few creative solutions emerged, including running DLLs in a "shim" subprocess to isolate their resources and using reference-counted tokens to manage access to DLL-associated resources. As it turns out, there's no one-size-fits-all answer, and the challenges of unloading DLLs cleanly are as old as they are nuanced.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
7h
Peak period
26
84-96h
Avg / period
6.4
Based on 32 loaded comments
Key moments
- 01Story posted
Aug 26, 2025 at 8:45 PM EDT
4 months ago
Step 01 - 02First comment
Aug 27, 2025 at 4:00 AM EDT
7h after posting
Step 02 - 03Peak activity
26 comments in 84-96h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 1, 2025 at 3:36 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
What if lib.B had been loaded explicitly somewhere else such that it did not appear in any other module's dependency list?
The only safe, consistent, reliable approach is not to close DLLs.
That doesn't address the need of some DLLs to malloc() resources in the context of the applications linking to them.
This problem _cannot_ be solved _generically_. Any solutions are extremely API-specific and impose restrictions on their users (the linking applications) which, if violated, will lead to Undefined Behavior.
Edit: as an example of cases which must bind resources in the application's context: see the Classloading in C++ paper at <https://wanderinghorse.net/computing/papers/index.html#class...> (disclosure: i wrote that article).
Of course, C/C++ applications written in the traditional model with static data everwhere would have difficulty not leaking tokens and holding the DLL open, but it's still far from impossible to write such a safe API.
> That doesn't address the need of some DLLs to malloc() resources in the context of the applications linking to them.
If there is a context boundary and really such a need, then the DLL can keep a list of all such resources, and destroy all those resources once closed. Access to them would similarly have to be protected by a token.
That's true, but those approaches are only viable if you trust the DLL in question. External libraries are fundamentally opaque/could contain anything, and if you're in a tinfoil-hat mood, it's quite easy to make new libraries that emulate the ABI of the intended library but do different (maybe malicious, maybe just LD_PRELOAD tricksy) things.
Consider: an evil wrapper library could put the thinnest possible shim around the "real" version of the library and just not properly account for resources, exposing library (un)loaders to use-after-free without much work, even if the library loaders relied upon the approaches proposed.
Since there aren't good cross-platform and race-condition-free ways of saying "authenticate this external library via checksum/codesigning, then load it", there are some situations where the proposed approaches aren't good enough.
Sure, most situations probably don't need that paranoia level (or control the code/provenance of the target library implicitly). But the number of situations where that security risk does come up is larger than you'd think, especially given automatic look-up-library-by-name-via-LD_LIBRARY_PATH-ish behavior.
Sign your libraries with Ed25519 and embed the public key in your app, verify before load. How is this not cross-platform enough?
Of course you still introduce a TOCTOU (time of check, time of use) race condition, which is why oftentimes you want to first check, load, then check again.
A common solution, however, is opening the library file once, then verify checksum/signature against trusted key, and if valid, create a private, unlinked temporary file (O_TMPFILE on Linux), write the verified contents into this temporary file, rewind and dlopen() (or LoadLibrary()) this temporary copy. Because the file is unlinked after creation (or opened with O_TMPFILE), no one else can swap it out, and you eliminate TOCTOU this way because you only ever read and load the exact bytes you verified. This is how container runtimes and some plugin systems avoid races. BTW on Linux you can use memfd_create() which creates an anonymous, in-memory file descriptor. You can do the same on Windows and macOS. Then you can verify the library's signature / hash, copy verified contents into a memfd (Linux) or FileMapping (Windows), and then load directly from that memory-backed handle.
TL;DR: never load from a mutable path after verification. Verifying untrusted binary bytes into a sealed memfd, for example, is race-safe.
FWIW, for applications I use firejail (not bubblewrap) for all applications such as my browser, Discord, LibreOffice, mupdf, etc. I recommend everyone to do the same. No way in hell I will give my browser access to files it does not need access to. It only has access to what it needs (related to pulseaudio, Downloads directory, etc), and say, no way I will give Discord access to my downloaded files (or my browser history) or anything really, apart from a directory where I put files I want to send.
The measures I suggested before were all in the context of buggy users that can't resist the urge to keep references to the library's resources lying around all over the place. But untrusted code can never be made safe with anything short of a strong sandbox.
The only safe, consistent, reliable approach is not to deallocate memory.
Why is tracking the lifetime of a function pointer different from tracking the lifetime of any other pointer?
FreeLibrary on Windows unloads libraries when the reference count is zero.
FYI just loading a DLL can execute code.
> Why is tracking the lifetime of a function pointer different from tracking the lifetime of any other pointer?
Technically speaking none, but historically this is something that nobody did, so we are full of code that assumes function pointers to have a static lifetime. It's a social problem.
The init function could return a status that indicates "already initialized."
The calling code could observe this and passively warn of the unusual condition but otherwise proceed.
As this article details, there are so many circumstances that preclude DLLs being unloaded completely that I was surprised that their design actually worked at all. So many language constructs do not play nicely with the idea that code and static data can just disappear at runtime.
[0] https://wiki.musl-libc.org/functional-differences-from-glibc...
A memory leak caused by a library isn't necessarily something that should prevent it from being unloaded. Unless it is the leaked objects that are holding a reference! (Then we need a full blown GC system to detect cycles.)
My guess they made an all-new Rust plugin which used an existing C++ library. Pretty common case when existing code base is slowly being converted to rust.
If the same file descriptor is open in another process (e.g. one that has it via fork(2) FD sharing either without child processes exec(2)ing or with CLOEXEC not set, or some older and esoteric abuses of fdpassing over UNIX sockets), then close(2) just decrements a refcount. The actual file isn't closed until the last holder of a reference to its file descriptor calls close(2).
This is rarely relevant, but when it comes up, it sure is wild. Common sources of confusion and pain due to this behavior are: files opened for "global library reasons" (e.g. /dev/shm buffers) in preforking servers, signalfd descriptors in preforking servers, processes that fork off and daemonize but leave their spawner around for e.g. CoW memory sharing efficiencies (looking at you, Python multiprocessing backends--the docs make it sound like they all act more or less the same, but in this regard they very much do not), libraries that usually swap STDIN/OUT/ERR file descriptors around with CLOEXEC disabled for a manually fork+exec'd child (e.g. situations where posix_spawn doesn't support needed pre-exec setup) but that are then used as part of larger applications that fork/spawn for other reasons and don't realize that file descriptor allocation/forking needs care and synchronization with the manually-fork/execing library in question: mixing forks and threads is one of those things that everyone says is a fast-track ticket to nasal demons, but that everyone also does regularly, I've found--if this describes you, be careful!
If you end up in one of those situations, suddenly invariants like "I called unlink on this path and then close(2)'d the descriptor to it, so that (maybe large) chunk of allocated space isn't taking up space on the filesystem/buffers any more" and "this externally-observable lockfile/directory is now unlocked due to its absence, now processes coordinating using that file on NFS will work as expected" no longer hold.
https://www.ibm.com/docs/en/aix/7.1.0?topic=domains-unix-dom...
I know that close(2)'s weirdness isn't a superset of dlopen(3)'s and there are different reasons for both behaviors. But it's still interesting that they "rhyme" as it were.
File descriptor = reference/pointer-ish thing.
File description = referenced data.
close(2) = decrement refcount to description by closing descriptor; actual destruction of the file's open-ness doesn't happen until refcount == 0.
One of the less well designed APIs, but as an aside it is still widely used for IPC.
Since the library is going away, it means it's not used any more. Not being used means that no thread that is currently running will call into that library any more.
If no thread that is currently running will use the code of that library, it has no business hanging on to the data belonging to the library; that data should only be manipulable via that code. Therefore, it should be forcibly taken away.
The reason they flunk on this issue is that there isn't a nice way to enumerate through all the threads and snipe away a particular class of thread local storage from each. The architecture is oriented around the POSIX-induced brain-damaged idea that a thread must clean up all thread-specific storage after itself.
Fight me!
Of course, if the library doesn't probably attempt to close libraries it's responsible for during its shutdown procedure, that's another can of worms.