For many years it was standard practice to test that you get the memory you ask for, but it was all a huge waste of time. Operating systems kick in before you have a chance to do anything.
We try to write code that behaves well – or most of us do. One particular disaster we’ve all learned to avoid is forgetfulness. The AC/C++ programmer uses the malloc function to allocate memory. The function usually returns a pointer to the requested memory, but if there is not enough memory, it returns a NULL. So we all usually wrote
handle out of memory problem
It’s so standard that it’s a copy-and-paste code snippet.
Now for the shock.
Malloc almost never returns a NULL, even if there is no memory available! In short, all that error-handling code is wasted code.
The point is that operating systems are responsible for allocating memory and they monitor the entire overall system. Your program running out of memory is a small consideration because it means that the whole machine, the operating system and all the programs it takes care of are at risk. The answer to the problem is the OOM – Out Of Memory killer. This is a monitoring process that checks if an application is about to use more memory than the system has. If so, it kills the process and therefore frees up memory for everything to continue.
OOM killers typically use heuristics to determine which processes to kill along with the one that actually precipitated the crisis. Usually, memory-intensive programs and low priority programs are selected, but it is difficult to predict the collateral damage of an OOM killer. This in itself is considered a drawback of the approach as the heuristic is by no means designed to be fair.
The big problem is that Moo’s killer doesn’t give the process any chance to gracefully handle the problem. In other words, the user could lose work due to lack of memory.
Some recent research When malloc() never returns NULL—Reliability as an illusion, which will be presented at ISSRE 2022, suggests that this is a bigger problem than you might think and one that needs more attention. Gunnar Kudrjavets, PhD student at the University of Groningen and his colleagues tried an experiment to see what really happens under different operating systems and discovered that only Windows allows malloc() to return NULL. Linux, Android, FreeBSD, iOS and macOS all killed the process and malloc was deprived of returning a NULL. In the case of all these operating systems, the memory consuming process was terminated along with others that matched the heuristic applied by the OOM killer. Why Windows? And is that a good or a bad thing? Is Windows just slow to adopt an OOM killer?
Basically, you can’t just test for a null when requesting more memory. The document outlines a number of strategies to overcome the problem, including monitoring memory availability before requesting an allocation.
His conclusion is:
“Universally checking the result of a memory allocation request has been standard practice for decades. Our recommendation to ignore this advice on a subset of operating systems is clearly contrary. However, development practices software must adapt to a new reality. This new reality means, for example, in the case of popular mobile operating systems such as Android and iOS, an application does not control what happens when an event occurs. OOM. Typical desktop applications that run in non-administrative mode have the same limitations. They cannot change operating system settings, query memory usage details of other applications, and cannot not bypass an official OOM killer to prolong their existence, therefore any code that is supposed to run when an OOM condition occurs will never run. uent, there is no reason for this code to be present.”
We all need to remember that our code’s interaction with the operating system is more complex than we usually realize, and that requesting a resource can result in termination without an opportunity to fix the problem.
There must be a better way.
- Harry Fairhead is the author of fundamental Cwhere it takes an in-depth look at C for use in any hardware-near context and Apply C for IoT with Linuxthe book you need if you do C coding that interacts with hardware.
Gunnar Kudrjavets (University of Groningen), Jeff Thomas (Meta Platforms, Inc.), Aditya Kumar (Snap, Inc.), Nachiappan Nagappan (Meta Platforms, Inc.) and Ayushi Rastogi (University of Groningen)
Linux to upgrade to C11
It’s the number one language again
Microsoft Making C Safe – C Verified
C Indefinite Behavior – Depressing and Terrifying (Update)
or send your comment to: [email protected]