Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory leak proof every C program

flak.tedunangst.com

Post reply on HN
Print view View original

101–110 of 175 posts

Re: Memory leak proof every C program

#101

Post by bluish29 »

mysterydip wrote: post #97
bluish29 wrote: post #95

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 I'm sure it would bring its own problems, could you just stick a semaphore or similar around the function?

Yes, but it will not work in a generic case because you have to handle the situations of deadlocks (i.e recursive mutexes for nested locking ..etc). Also you will introduce more problems of creating performance deadlocks. There will not be out of box solutions to all these. Once you start considering solving case on its own then this does not provide out of box solution as the original premise.

Re: Memory leak proof every C program

#103

Post by Diggsey »

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...)

Re: Memory leak proof every C program

#104

Post by aeyes »

jamal-kumar wrote: post #79
WhackyIdeas wrote: post #76

Earlier quoted context omitted.

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 solu…

The last part is funny. Even if you are technically not leaking memory you can still have pretty much the same end result in garbage collected languages if you mess up. The language might be tracking the objects but it can't know if you don't need them anymore.

Re: Memory leak proof every C program

#105

Post by [deleted] »

mysterydip wrote: post #97
bluish29 wrote: post #95

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 I'm sure it would bring its own problems, could you just stick a semaphore or similar around the function?

[deleted]

Re: Memory leak proof every C program

#106

Post by linkdd »

bluGill wrote: post #90
kbenson wrote: post #54

Earlier quoted context omitted.

The difference is that if you're writing a program you know the scope of use of all libraries, whether they be externally loaded or internal abstraction boundaries, and also know the scope of use of the program, and can make a call as to whether cleanup during opetation is required.

Not really. In theory you can, but in practice there are parts written by a different team and you don't know the scope of there parts. I also know someone who maintains some Clinton era encryption. that code is controlled who can know about it as obsecurity was all you were allowed. There are other pathalogical cases where you can't know everything about your program-

Obviously, the "free-less programs" are not a "one size fits all" option. Like pretty much everything in IT and the dev world.

Re: Memory leak proof every C program

#107

Post by lifthrasiir »

rco8786 wrote: post #41
enriquto wrote: 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.

Many online games regularly schedule a downtime often to simply restart the process and "solve" moderate memory leaks.

Re: Memory leak proof every C program

#108

Post by wegfawefgawefg »

tetromino_ wrote: post #64
HideousKojima wrote: post #51

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.

But sir!! They were nazi orphans!

Re: Memory leak proof every C program

#109

Post by zlsa »

tetromino_ wrote: post #64
HideousKojima wrote: post #51

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.

Related: the Ariane 5 rocket failed on its maiden flight because it reused code from its predecessor, which made an assumption that didn't apply to the higher-performance Ariane 5.

https://en.wikipedia.org/wiki/Ariane_flight_V88

Re: Memory leak proof every C program

#110

Post by akoboldfrying »

mysterydip wrote: post #97
bluish29 wrote: post #95

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 I'm sure it would bring its own problems, could you just stick a semaphore or similar around the function?

We're deep in a ridiculous scenario here, but the answer is that, yes, this would result in a safe program, provided that it never calls malloc() from a signal handler (since that would deadlock if the interrupted code had already grabbed the lock/mutex/semaphore/whatever).

In any other scenario, if some execution thread reaches the point where it returns from calling lock() on the mutex guarding malloc(), it must eventually reach the call to unlock().

Post reply on HN