Live data from Hacker News

Memory leak proof every C program

flak.tedunangst.com

151–160 of 175 posts

Re: Memory leak proof every C program

#151
post #80

Earlier quoted context omitted.

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.

A lot of game engines do this, avoiding the cost of a malloc lookup by just allocating everything as a stack

I remember seeing a Java game engine that included a container that you were supposed to dump unused objects into to prevent GC from running in the middle of a level. At the end of the level, you could empty the container, and let the GC run during the loading screen or whatever.

It was a deliberate design choice that was surprisingly close to what the original article describes.

Re: Memory leak proof every C program

#152
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…

> Unless your program is long-running

... or unless someone decides to convert it into a daemon "because of that ticket" and then QA goes all "oh, ah, the routing is dead, the sshd is dead and the whole box is all but bricked, what could've possibly caused that".

Re: Memory leak proof every C program

#153

Earlier quoted context omitted.

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?

Plenty of cases fit the case, e.g. if it's some sort of server, you assign a separate allocator to each request and then purge it once the request is processed.

Re: Memory leak proof every C program

#154
post #87

Earlier quoted context omitted.

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 */

Nitpick: for maximum source compatibility, use this instead: #define free(_) ((void)0)

Technically _ needs to be evaluated by the macro to support cases like free(p++).

Re: Memory leak proof every C program

#156
post #123

Earlier quoted context omitted.

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

Why isn't it serious? I can imagine a smart pointer that actually accomplished the stated goal. So the joke is that they took a good idea and made a rubbish solution?

smart pointers in C?

Re: Memory leak proof every C program

#157
post #80
post #41

Earlier quoted context omitted.

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.

Standard approach in systems for critical applications like aerospace: https://www.quora.com/How-does-SpaceX-handle-memory-manageme...

Re: Memory leak proof every C program

#158
post #129

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…

That style of #ifdef use, while common in the past, tends to be somewhat fragile and also gets more and more tangled as more conditions are added.

A better way is to have an always existing inline running_on_valgrind() function, and use the #ifdef only for that function definition, either within it or around it (having it around the function also allows it to be inline only for the trivial not-defined case). Examples of this "inline function" style are found all over the Linux kernel (which has lots of conditionally-compiled code).

Re: Memory leak proof every C program

#159
post #87

Earlier quoted context omitted.

Nitpick: for maximum source compatibility, use this instead: #define free(_) ((void)0)

Technically _ needs to be evaluated by the macro to support cases like free(p++).

hmm right... wouldn't this work then?

    #define free(e) ((void)(e))

Re: Memory leak proof every C program

#160
post #33

Earlier quoted context omitted.

that's the joke...

it's not funny, it's not obvious and it's wasting a lot of people's time. ha. ha. ha.

It's quite obvious...

"If you don’t call free, memory usage will increase over time, but technically, it’s not a leak."

Post reply on HN