undefined | Better HN

0 pointsderefr4y ago0 comments

If you mean “why isn’t it disabled by default on Linux installs”: most programs don’t expect malloc(2) to ever return NULL. Those programs will just assume the return value from malloc(2) is valid memory. In the best case, they’ll immediately write to it and protection-fault. In the worst case, they’ll hold onto this NULL pointer for a while, passing it around, until eventually something else somewhere distant in the program blows up some unknown amount of time later.

Even those programs that are “malloc(2) error aware”, often do something stupid and counterproductive in response, like attempting to allocate more memory for an exception object / stack trace / error string.

Programs that do something useful in response to a NULL malloc(2) return result — useful for the stability of the system as a whole, better than what the OOM killer gets you — are rare, even on servers. Usually it’s only stateful, long-running, DBMS-like daemons that 1. bother, and 2. have the engineering effort put into them to do the right thing.

0 comments

mjw10074y ago

I think your first paragraph is too pessimistic.

You can get a decent idea of the behaviour of the programs you use when they run out of memory by running under 'ulimit -v' with a low limit.

In my experience most (though far from all) of the programs I use managed a clean abort with an error message (as from a traditional xmalloc()).

derefrOP4y ago

Most of these were likely managed-language programs.

Programs witten for managed language runtimes will have a language-runtime-level abort on malloc(2) fail, which usually is well written, in the sense that it will clean up language-runtime-level resources, and emit a language-runtime-level error message.

But this language-runtime-level abort usually isn’t exposed to the application in any hookable way, so from the developer’s perspective, it’s basically the same as being OOM killed. There’s no option to clean up e.g. an individual transaction’s resources in order to keep going. There’s no hooks for libraries to use to e.g. properly send close messages on sockets (if the language runtime doesn’t do that itself as part of managing socket lifetimes.) Etc.

These managed runtimes (e.g. the JVM) may expose a catchable exception for OOM errors, but these are for internal, language-runtime level OOM errors, triggered by the runtime itself under certain conditions, rather than in response to a syscall failure. When malloc(2) fails, it’s basically “too late” from these runtimes’ perspectives — they no longer have the resources required to allow the user to run any more code.

mjw10074y ago

« Most of these were likely managed-language programs. »

Please don't guess. They weren't.

It is true that a program that aborts as soon as malloc returns failure isn't doing any special cleanup or attempting to keep going.

But that's not at all the same as « Those programs will just assume the return value from malloc(2) is valid memory. In the best case, they’ll immediately write to it and protection-fault. », which is what I'm informing you is too pessimistic.

1 more reply

j / k navigate · click thread line to collapse

0 pointsderefr4y ago0 comments

0 comments

mjw10074y ago

I think your first paragraph is too pessimistic.

You can get a decent idea of the behaviour of the programs you use when they run out of memory by running under 'ulimit -v' with a low limit.

In my experience most (though far from all) of the programs I use managed a clean abort with an error message (as from a traditional xmalloc()).

derefrOP4y ago

Most of these were likely managed-language programs.

mjw10074y ago

« Most of these were likely managed-language programs. »

Please don't guess. They weren't.

It is true that a program that aborts as soon as malloc returns failure isn't doing any special cleanup or attempting to keep going.

1 more reply

j / k navigate · click thread line to collapse