Memory leak proof every C program
A tongue‑in‑cheek blog post proposes “fixing” C memory leaks by intercepting `malloc` and storing every allocation in a global list, so leak detectors see everything as still reachable—at the cost of actually leaking and corrupting memory. Commenters unpack why this is unsafe and misleading, contrast it with real tools like Valgrind and LeakSanitizer, and use it as a springboard to talk about when it’s acceptable not to free memory (short‑lived processes, arenas, FaaS) versus when robust memory management, RAII, or garbage collection are essential.
Seriousness of the proposal
- Many commenters see the post as clearly tongue‑in‑cheek, meant to demonstrate how trivially leak detectors can be fooled, not as a production technique.
- Others note that the code looks plausible enough that less‑experienced C programmers might mistake it for a real solution, which worries them.
Technical critique of the “bigbucket” malloc wrapper
- The wrapper only tracks allocations in a global list; it never removes entries, even when user code calls
free. - This produces true leaks: heap memory used by the tracking list grows without bound, and the stored pointers become dangling after frees.
- It can exhaust memory even for programs that correctly free everything in a loop.
- It is not thread‑safe and pays a high cost by calling
dlsymon every allocation. - Some note you could “complete” the joke by redefining
freeas a no‑op to avoid dangling pointers entirely.
Definition of leaks vs. unbounded memory growth
- Several point out that “reachable” memory can still be a leak in practice; GC’d languages can leak via forgotten references.
- Others emphasize that what really matters is unbounded memory consumption, not whether memory is technically reachable.
Intentional non‑freeing in real systems
- Many examples are given where not freeing is intentional and acceptable: short‑lived programs, CGI/PHP‑style per‑request processes, arena/per‑request allocators, HFT systems, some game/audio engines, missiles or specialized embedded systems, and servers that periodically restart.
- Some argue freeing at program exit is often pointless and can even hurt performance (e.g., page faults when tearing down large heaps).
Leak detection tools and practical strategies
- Commenters recommend real tools like Valgrind and LeakSanitizer, and patterns like arenas, per‑module leak‑free design, and selective freeing of the “hot paths” that dominate allocations.
- A trick mentioned: only run full cleanup logic when under a leak checker (e.g., detecting Valgrind at runtime).
Meta and measurement issues
- The thread repeatedly invokes the idea that if you only optimize for “no leaks under tool X,” people will game that metric (Goodhart’s law).
- Several note that in large codebases, true leaks are rarer than memory bloat from retained but unused data, which is harder to find and affects all languages.