Memory leak proof every C program

This is the core idea:

> It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.

This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when the program ends. Free-less C programming is an exhilarating experience that I recommend to anybody.

In the rare cases where your program needs to be long-running, leaks may become a real problem. In that case, it's better to write a long-running shell script that calls a pipeline of elegant free-less C programs.

This solution doesn't do anything to prevent leaking memory in anything but the most pedantic sense, and actually creates leaks and dangling pointers.

The function just indirects malloc with a wrapper so that all of the memory is traversable by the "bigbucket" structure. Memory is still leaked in the sense that any unfreed data will continue to consume heap memory and will still be inaccessible to the code unless the application does something with the "bigbucket" structure--which it can't safely do (see below).

There is no corresponding free() call, so data put into the "bigbucket" structure is never removed, even when the memory allocation is freed by the application. This, by definition, is a leak, which is ironic.

In an application that does a lot of allocations, the "bigbucket" structure could exhaust the heap even though there are zero memory leaks in the code. Consider the program:

  int main(int argc, char** argv) {
    for (long i = 0; i < 1000000; i++) {
      void *foo = malloc(sizeof(char) * 1024);
      free(foo);
    }
    return 0;
  }

At the end of the million iterations, there will be zero allocated memory, but the "bigbucket" structure will have a million entries (8MB of wasted heap space on a 64-bit computer). And every pointer to allocated memory in the "bigbucket" structure is pointing to a memory address previously freed so now points to a completely undefined location--possibly in the middle of some memory block allocated later.

There are already tools to identify memory leaks, such as LeakSanitiser https://clang.llvm.org/docs/LeakSanitizer.html. Use those instead.

Obviously this is a joke, but the real message should be: if you can't manage your own memory, you should be using a language implementation with automatic memory management. If your code really needs to run "close to the metal", you really need to figure out how to manage your memory. In 2024, language implementations without automatic memory management should be reserved for applications that absolutely need them.

I bet this is what some people on my team would come up with if the ticket acceptance criteria said "program must not leak memory when checked with valgrind"

I've got an idea...

We have a counter that goes up by 1 every time you call malloc.

And down by one every time you call free.

And when the program quits, if the counter isn't zero, an email is fired off and a dollar gets sent from the developers bank account to the users bank account...

There is a bug here... Clearly the author intended to cache the value of nextmalloc to avoid calling dlsym() on every malloc. The correct code should be:

  static void *(*nextmalloc)(size_t) = NULL;
  if (!nextmalloc) 
    nextmalloc = dlsym(RTLD_NEXT, "malloc");
  }

Somehow the fact that the optimization is incorrectly missed here feels appropriate ;-)

I have a much better and practical solution: https://github.com/LibreDWG/libredwg/blob/7d9fc3da44bbdb60a4...

    #ifdef HAVE_VALGRIND_VALGRIND_H
      if (RUNNING_ON_VALGRIND)
    #endif
        free_all() 

free is way too slow if not needed, so detect valgrind via its API. Just on valgrind do the unnecessary free dance. ASAN's memleak detector is disabled via its env.

Perl5 does its final destruction similarly, only when it has important destructors (like IO, DB handles and such) to call.

Hahahahaha I love this! Almost as good as fixing race conditions with sleep statements ( which I see a lot )

This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyway.

I used to really struggle with memory leaks in C++, until smart pointers came along. I think the only leak I've investigated since then wound up being an actual bug in the MSVC standard library.

OS handles and such are still an issue, but you can wrap them too. Thank goodness for RAII, a fantastic reason to use C++ even if you're otherwise writing C-like code.

This doesn't make sense even as a joke, since that's not what it means to leak memory.

Memory being "reachable" is a property used by garbage collectors to determine what can be safely freed, but reachable memory can still be a memory leak. (Which is why languages with GC can still suffer from memory leaks...)

Thank you for playing Wing Commander!

Reminds me of a situation I encountered with Salesforce code many years ago. Salesforce had a requirement that their test platform had to cover some percentage of the lines of code in the Sandbox before you could deploy something to production.

Our Salesforce implementation consultants had put 500 lines of 'x = 1' into a piece of code to force it to deploy -- and these were people at a top consulting company with a very lucrative hourly rate.

No idea if SFDC still works this way or if this would fly today, this was back in the days when you had to use Flex to integrate anything with the UI.

I'm concerned about how a non-zero number of people here on HN seem to think this is meant seriously.

This not bulletproof method to handle memory leaks as it still keeps all allocations. It simply keeps a list of all allocations but doesn't address the core issue of unnecessary memory consumption if free is not called. But the more pressing problem is that this implementation is not thread safe. Concurrent accesses to the bigbucket list in a multi-threaded programs can easily lead to race conditions

While this is a joke, it somewhat resonates with my experience of working on a huge C++ project (search engine, tens of millions of lines).

Over the years I had been debugging multiple memory problems and only once I had found a true memory leak. It wasn't the bug I was looking for, accounting for only 8 bytes per hour and it was the easiest of all: directly discovered by valgrind.

All others were memory bloat cases: memory reachable but not used. Like forgetting some small per-request descriptor in some auxiliary hashmap in one of the code pathways. Reproducing and debugging was pain because it required running a loaded backend for days under a profiler, before the bloated part becomes visible.

Funny thing is that while C++ is notorious for memory leaks this particular kind of problem is possible in any language that allows a global mutable state (so all the practical ones). From experience it seems that true leaks are unlikely in a reasonably-good C++ code. Just never mix business logic with memory management and you're good to go.

This is not thread safe.

This is a joke, yet this is basically a very rudimental form of malloc() auditing tool. Because at the end of the program, it could show you all the stuff that is yet allocated, and even scan the program whole memory for the pointers and report only the ones not found.

“Hey I might need that later!”

Memory hoarding. I hate it but I love it.

From the comments I get the impression that we have all worked with someone that would have considered this an actual solution and we had to talk them out of it.

If only I had known this earlier in my career! They should really add a feature to make a hard copy of the big bucket list to minimize memory overhead, though.

While subtle, your point was not lost on me!

Technically all pointers are accessible, but the issue remains that we have not logically accounted for unused resources and are wasting capacity. In this sense, memory leaks are possible in all languages. We could store every object into a global structure, and it will never be freed in any language. Thus, my Rust program balloons forever.

Since my computer memory isn't draining out my computer and down into the sewers, all my programs must therefore be leak proof.

In the same spirit, here's a fun talk about tool that guarantees 100% line coverage for your Python tool: https://www.youtube.com/watch?v=A-cjMRsHcXI

After running your test suite, it kicks into action and deletes all the lines of your code that were never executed.

Since this seems to be some sort of joke i'm going to provide a "real" answer: write modular software where you can verify that each module is leak proof + use valgrind to actually track and verify you don't have links.

I have written medium to large projects using this approach and a leak-free program is not outside the realm of possible

Although this is a joke, from a systems perspective this is a valid strategy - stateless lambda (FAAS) functions can use this strategy as the state is moved externally, and can take the load of say long running monitoring processes.

All arena-apologists hate this little trick

I totally thought this was an April fools joke at first. Why is this front page?

To avoid an bugs, you can add a `exit(0)` at the beginning of your program.

This one weird trick will fix your memory leaks forever

Will this land in OpenBSD, given Ted is a core dev?

> Problem sovled!

Now if we could just fix off-by-one errors.

The problem, as he says, is indeed sovled.

hahaha: "Problem sovled!" [sic]