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

21–30 of 175 posts

Re: Memory leak proof every C program

#21

Post by omoikane »

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…

This solution did not override "free" to free the extra struct, so calling free is in fact not optional but probably a bad idea. Need an extra patch:

    #define free(_) /* no-op */

Re: Memory leak proof every C program

#22

Post by tenebrisalietum »

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…

I always thought that was one reason the UNIX terminal login process (with `getty` and `exec` to shell, getty restarting when the shell exits) was the way it was.

Re: Memory leak proof every C program

#23

Post by codetrotter »

hnlmorg wrote: post #20
f321x_ wrote: post #16

Earlier quoted context omitted.

[flagged]

It’s definitely inelegant. But I wouldn’t say it’s entirely without merit. If you’re writing a very simple “sed” like utility then you could probably get away without freeing. That all said, the kind of problems were freeing becomes complicated is generally the kind of software that is more complex than your typical “sed” command. So the advise of not freeing doesn’t really address the domain where freeing is a risk.

Kind of sucks for the first person that tries to process a really big file with it.

Programmer never free’d, and only ran it on files that were like some hundred megabytes big.

Some poor schmuck tries to process a 15 GB file on his 8 GB RAM machine, and after running for hours it crashes because of the lack of free :(

Re: Memory leak proof every C program

#24

Post by TillE »

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.

Re: Memory leak proof every C program

#26

Post by linkdd »

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.

If you're writing a library, you're not writing a program.

If you write a C library, it is a good practice to leave the allocations to the library user, or at least provide a way to override the library's allocator. Allowing your user to write a free-less *program*.

Re: Memory leak proof every C program

#27

Post by hnlmorg »

codetrotter wrote: post #23
hnlmorg wrote: post #20

Earlier quoted context omitted.

It’s definitely inelegant. But I wouldn’t say it’s entirely without merit. If you’re writing a very simple “sed” like utility then you could probably get away without freeing. That all said, the kind of problems were freeing becomes complicated is generally the kind of software that is more complex than your typical “sed” command. So the advise of not freeing doesn’t really address the domain where freeing is a risk.

Kind of sucks for the first person that tries to process a really big file with it. Programmer never free’d, and only ran it on files that were like some hundred megabytes big. Some poor schmuck tries to process a 15 GB file on his 8 GB RAM machine, and after running for hours it crashes because of the lack of free :(

That’s assuming each byte and/or line item is a new allocation rather than reusing already allocated memory for lines that have already been parsed.

Plus not every utility needs to consider large file usage. Eg a date/time formatter.

To be clear, I’m not advocating that people shouldn’t free. Just saying things aren’t always black and white.

A great example of this is one of Americas missile guidance systems famously has a memory leak. But it runs out of memory after its maximum range anyway. So the memory leak doesn’t affect the performance of the missile in any scenario.

Technology is often nuanced.

Re: Memory leak proof every C program

#28

Post by IshKebab »

kelthan wrote: 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?

Re: Memory leak proof every C program

#30

Post by MrJohz »

linkdd wrote: post #26
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.

If you're writing a library, you're not writing a program. If you write a C library, it is a good practice to leave the allocations to the library user, or at least provide a way to override the library's allocator. Allowing your user to write a free-less *program*.

Any large program is composed of libraries. They may not explicitly be described as libraries, or imported from external sources, but there will be abstraction boundaries somewhere.

Which means that if you're writing a program, you probably are also writing one or more libraries.

Post reply on HN