Live data from Hacker News

Memory leak proof every C program

flak.tedunangst.com

71–80 of 175 posts

Re: Memory leak proof every C program

#71

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.

Funny, I think the lesson is the opposite: just because you have mechanisms that technically prevent memory leaks doesn't mean that you don't need to think about memory and its allocation/freeing. Or rather, memory leaks generally are not problem, unbounded memory consumption is, regardless if the consumption is technically due leak or some reference stashed somewhere.

Re: Memory leak proof every C program

#72

Earlier quoted context omitted.

Are you saying PHP creates a new process for each request?

It's been a while since I used PHP, but this is something controlled by the server used. If you use Apache then it used to create a new process for each request, yes.

Even in the classic prefork model (and mod_php), Apache did recycle worker processes. Only CGI operated on this new process for each request.

Re: Memory leak proof every C program

#74
post #3

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…

A professor actually told us that freeing prior to exit was harmful, because you may spend all of that time resurrecting swapped pages for no real benefit. Counterpoint is that debugging leaks is ~hopeless unless you have the ability to prune “intentional leaks” at exit

> debugging leaks is ~hopeless unless you have the ability to prune “intentional leaks” at exit

Not in general. It depends on your debugger. For example, valgrind distinguishes between harmless "visible leaks", memory blocks allocated from main or on global variables, and "true leaks" that you cannot free anymore. The first ones are given a simple warning by the leak detector, while the true leaks are actual errors.

Re: Memory leak proof every C program

#75
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.

Re: Memory leak proof every C program

#76
post #2

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…

Uhm... woosh! You know this isn't serious right?

I just hope ChatGPT could see it was a joke

Re: Memory leak proof every C program

#77

Earlier quoted context omitted.

Or the missile firmware where the missile is going to explode before they run out of memory: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

Using warhead explosion as garbage collector might seem like a clever hack, but all it takes is an upgrade by a different team (say, adding a new engine, or longer-range sensors, or repurposing a surface-to-air missile for a surface-to-surface role), and suddenly your guidance software runs out of memory before it explodes, and your missile falls onto an an elementary school or hospital.

You can probably double the ram (or more) again by then.

Re: Memory leak proof every C program

#78

Earlier quoted context omitted.

Why would FFI be an issue?

Maybe you allocate a string and pass it to Rust code. Then the Rust code needs a way to free it (through `drop`).

1st approach) you don't

2nd approach for when you ignore the first) you use a type that doesn't "own" the pointer, and have the FFI side that allocated it free it

3rd approach for when you find out you can't do the 2nd) hope that the "owned" type is actually generic over the allocator used, and make an allocator that doesn't free (or even better, calls the correct free over the FFI boundary). `allocator-api` is the effort in this direction.

Re: Memory leak proof every C program

#79

Earlier quoted context omitted.

Uhm... woosh! You know this isn't serious right?

I just hope ChatGPT could see it was a joke

I posted the post into that and it said this:

While the provided code may seem like an interesting approach, it's important to note that it introduces a number of issues and potential pitfalls. This code is an attempt to intercept the malloc function using the dlsym function from the dlfcn.h library and store every allocated pointer in a linked list called bigbucket. However, there are several problems with this solution:

    Portability: This code relies on the dynamic linking functionality provided by the operating system. It may not work on all systems or with all compilers.

    Concurrency Issues: This solution is not thread-safe. If the program uses multiple threads, concurrent calls to malloc may result in race conditions and data corruption in the bigbucket linked list.

    Incomplete Solution: This code only intercepts calls to malloc. If the program uses other memory allocation functions like calloc, realloc, or custom memory allocators, memory leaks may still occur.

    Performance Overhead: The code introduces additional overhead for every memory allocation, potentially affecting the program's performance.

    Undefined Behavior: Overriding standard library functions like malloc can lead to undefined behavior. The behavior of the program is no longer guaranteed to be consistent across different platforms or even different runs.

    Limited Practicality: While this approach technically prevents memory leaks by keeping track of all allocated pointers, it does not address the root cause of memory leaks, which is the failure to deallocate memory when it is no longer needed. Encouraging developers not to free memory is not a good practice and can lead to inefficient memory usage.
A better approach to avoiding memory leaks is to adopt good programming practices, such as carefully managing memory allocation and deallocation, using automated tools like static analyzers and memory debuggers, and, when applicable, leveraging programming languages with automatic memory management (e.g., garbage collection in languages like Java or Python).

Re: Memory leak proof every C program

#80
post #41
post #3

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…

Reminds me of the HFT shop that built in Java and simply turned the garbage collector off. Then when the market closed they would restart the process for the next day.

I had a friend who worked for one of the big Market Makers, and he told me that they would indeed turn the GC off, but what they'd do is just pre-allocate everything into bigass arrays before-hand, and have incrementers to simulate the "new" keyword. They might do this in something more or less like a threadlocal to avoid having to deal with locks or race conditions or anything like that.
Post reply on HN