5 ms·

> They just never free memory and deliberately leak it until they exit Which is a great way to kill that process, or arbitrary processes, when a previously wel

by derleth 13y ago

> They just never free memory and deliberately leak it until they exit Which is a great way to kill that process, or arbitrary processes, when a previously well-behaved program is run on a system that's a bit strapped for RAM at the moment, or run on a somewhat larger-than-usual input, or both. That, or bring the system to a standstill as the swapping subsystem flogs the disk nonstop. Possibly first one, and then the other.

xyzzy123 13y ago
Well, you never have guarantees that this won't happen even if you free(). Reasonable resource consumption is an engineering decision based on context (target, expected problem size, etc). Deliberate leaking is IMHO a totally viable engineering strategy. If anything, behaviour is actually more reliable and predictable than the alternatives apart from "upfront static allocation". If you ran into problems and want the entire system to behave predictably, you could on Linux disable vm overcommit, set oom_adj (so leaker proc gets killed preferentially), set strict ulimits and ensure abort() on malloc failure. However if you have to go to these lengths, leaking might not be appropriate ;)
nostrademons 13y ago
For a lot of these simple command-line utilities, it wouldn't matter anyway. They often work by building up some data structure that's then used to process the rest of the input line-by-line, and then the program exits. If the data structure is never freed, so what? It's needed until the end of execution anyway. Think of compiled regular expressions for grep, or total counts for wc, or a rotating line buffer for tail, or the previous line for uniq. It's quite possible to get pathological behavior even with GC or careful RAII, as anyone who's ever leaked memory in a Java program could tell you. Simulating a computer with infinite memory breaks down when the working set you're touching exceeds the physical RAM of the machine. Actually, leaking memory is the least of your concerns in that case, as leaked memory just gets paged out and doesn't cause any problems unless it exceeds the computer's address space.
- andrewflnr 13y ago
  Actually, with tail -f that could become a problem.
  - rcthompson 13y ago
    I don't see how it could. Tail doesn't use more memory as it reads more lines. It sets up a fixed-size buffer and then continually re-uses it. Yes, "tail -f" could be a long-running process, but its memory usage should remain constant over its entire lifetime.
Retric 13y ago
If your five orders of magnatude below system RAM and the OS runs out of memory then it's someone else's problem. Granted the system might runout of swap space due to say the 100kb you allocated but reolistically other things that take up ~100,000 times as much space collectively are the actual problem.
mikeash 13y ago
What kind of systems are you running where a few hundred kilobytes of allocation on a machine with gigabytes of memory can "bring the system to a standstill"?

by derleth 13y ago

xyzzy123 13y ago

Well, you never have guarantees that this won't happen even if you free(). Reasonable resource consumption is an engineering decision based on context (target, expected problem size, etc). Deliberate leaking is IMHO a totally viable engineering strategy. If anything, behaviour is actually more reliable and predictable than the alternatives apart from "upfront static allocation". If you ran into problems and want the entire system to behave predictably, you could on Linux disable vm overcommit, set oom_adj (so leaker proc gets killed preferentially), set strict ulimits and ensure abort() on malloc failure. However if you have to go to these lengths, leaking might not be appropriate ;)

nostrademons 13y ago

For a lot of these simple command-line utilities, it wouldn't matter anyway. They often work by building up some data structure that's then used to process the rest of the input line-by-line, and then the program exits. If the data structure is never freed, so what? It's needed until the end of execution anyway. Think of compiled regular expressions for grep, or total counts for wc, or a rotating line buffer for tail, or the previous line for uniq. It's quite possible to get pathological behavior even with GC or careful RAII, as anyone who's ever leaked memory in a Java program could tell you. Simulating a computer with infinite memory breaks down when the working set you're touching exceeds the physical RAM of the machine. Actually, leaking memory is the least of your concerns in that case, as leaked memory just gets paged out and doesn't cause any problems unless it exceeds the computer's address space.

andrewflnr 13y ago
Actually, with tail -f that could become a problem.
- rcthompson 13y ago
  I don't see how it could. Tail doesn't use more memory as it reads more lines. It sets up a fixed-size buffer and then continually re-uses it. Yes, "tail -f" could be a long-running process, but its memory usage should remain constant over its entire lifetime.

Retric 13y ago

If your five orders of magnatude below system RAM and the OS runs out of memory then it's someone else's problem. Granted the system might runout of swap space due to say the 100kb you allocated but reolistically other things that take up ~100,000 times as much space collectively are the actual problem.

mikeash 13y ago

What kind of systems are you running where a few hundred kilobytes of allocation on a machine with gigabytes of memory can "bring the system to a standstill"?