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

91–100 of 175 posts

Re: Memory leak proof every C program

#91

Post by ramses0 »

RustyRussell wrote: post #36
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…

Hilarious! But I remember the first time I saw such a program which never freed anything: jitterbug, the simple bug tracker which ran as a CGI script. It indeed allows a very simple style! Meanwhile, use ccan/tal ( https://github.com/rustyrussell/ccan/blob/master/ccan/tal/_i... ) and be happy :)

I did a watch face on pebble once... the programming style was "uncommon" when you're hardcoding the ONE watch face that is currently rendering the screen. It "felt" very leaky and illegal... but it's a watch face with limited functionality, so... shrug?

Re: Memory leak proof every C program

#93

Post by etimberg »

klyrs wrote: post #7
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…

In the not-rare case where you're writing a library, or wrapping a utility, the last programmer's exhilaration is your pain.

Early in my career I saw the aftermath of someone trying to deal with this problem. The solution they went with was to replace all allocations in the offending code with a custom allocator and then just throw the allocator away every so often

Re: Memory leak proof every C program

#94

Post by gnufx »

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…

The canonical free-less (or no-op free) solution is conservative GC, isn't it? Specifically the Boehm collector..

Re: Memory leak proof every C program

#95

Post by bluish29 »

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

Re: Memory leak proof every C program

#96

Post by diziet_sma »

x86x87 wrote: post #66

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

This does help, but the hard part of memory leaks is leaks across module/api boundaries. You can write a memory safe module, I can write a memory safe program, but when my program starts calling your program there's nothing validating I'm maintaining the invariants required to avoid memory leaks.

Hopefully the invariants are documented, but relying on documentation to help programmers avoid memory leaks is far from foolproof.

Re: Memory leak proof every C program

#97

Post by mysterydip »

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?

Re: Memory leak proof every C program

#98

Post by jbboehr »

tonyedgecombe wrote: post #49
skrebbel wrote: post #42

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.

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

It depends on the SAPI. The php-fpm approach is a pool of processes that are reused for multiple requests. Virtually all of the state visible to plain PHP code is reset between requests, however some interpreter/runtime state is kept, e.g. in-memory bytecode cache, initialized extensions, some persistent network connections, etc.

In terms of memory management, PHP has both reference counting and garbage collection. Internally, an arena per request is used[0], so leaking memory over long periods of time is fairly rare and usually limited to native extensions.

[0]: https://www.phpinternalsbook.com/php7/memory_management/zend...

Re: Memory leak proof every C program

#99

Post by akoboldfrying »

etimberg wrote: post #93
klyrs wrote: post #7

Earlier quoted context omitted.

In the not-rare case where you're writing a library, or wrapping a utility, the last programmer's exhilaration is your pain.

Early in my career I saw the aftermath of someone trying to deal with this problem. The solution they went with was to replace all allocations in the offending code with a custom allocator and then just throw the allocator away every so often

Was there any way for them to know when it was safe to do so? If not: Wouldn't stopping and restarting the program be better?

Re: Memory leak proof every C program

#100

Post by Taniwha »

lgg wrote: post #82

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

yeah exactly, calling dlsym on every malloc would kill performance

the other bug of course is that it's not thread safe

Post reply on HN