+- 0Day Forums (https://0day.red)
+-- Forum: Coding (https://0day.red/Forum-Coding)
+--- Forum: C & C++ (https://0day.red/Forum-C-C)
+--- Thread: What is the correct way to handle "out of memory"? (/Thread-What-is-the-correct-way-to-handle-quot-out-of-memory-quot)
What is the correct way to handle "out of memory"? - vivasfianwjvlpa - 07-26-2023
Recently, I work on a video player program on Windows for a CCTV program. As the program has to decode and play many videos streams at the same time, I think it might meet the situation that malloc will fail and I add checking after every malloc.
But genrally speaking, in these code of open source programs that I've read in open source projects, I seldom find any checking of result of malloc. So when malloc fails, most program will just crash. Isn't that unacceptalbe?
My colleagues who write server programs on linux will alloc a enough memory for 100 client connections. So although his program might refuse the 101 client, it will never met a failure of malloc. Is his approach also suitable for desktop applications?
RE: What is the correct way to handle "out of memory"? - beckienppmo - 07-26-2023
On Linux, `malloc()` will never fail -- instead, the OOM killer will be triggered and begin killing random processes until the system falls over. Since Linux is the most popular UNIX derivative in use today, many developers have learned to just never check the result of `malloc()`. That's probably why your colleagues ignore `malloc()` failures.
On OSes which support failures, I've seen two general patterns:
* Write a custom procedure which checks the result of `malloc()`, and calls `abort()` if allocation failed. For example, the [GLib and GTK+](
[To see links please register here]
) libraries use this approach.* Store a global list of "purge-able" allocations, such as caches, which can be cleared in the event of allocation failure. Then, try the allocation again, and if it still fails, report it via the standard error reporting mechanisms (which do not perform dynamic allocation).
RE: What is the correct way to handle "out of memory"? - giril - 07-26-2023
To use the result of malloc without checking for null is unacceptable in code that might be open to use on platforms where malloc can fail, on those it will tend to result in crashes and unpredicatable behaviour. I can't forsee the future, don't know where my code will go, so I would write code with checks for malloc returning null - better to die than behave unpredicatbly!
Strategies for what to do if malloc fails depend upon the kind of applciation and how much confidence you have in the libraries you are using. It some situations the only safe thing to do is halt the whole program.
The idea of preallocating a known quota of memory and parcelling out in some chunks, hence steering clear of actually exhausting the memeory is a good one, if your application's memory usage is predicatable. You can extend this to writing your own memory management routines for use by your code.
RE: What is the correct way to handle "out of memory"? - foals516556 - 07-26-2023
Always check, and pre-allocate a buffer that can be freed in this case so you can warn the user to save his data and shut down the application.
RE: What is the correct way to handle "out of memory"? - Mriulus10 - 07-26-2023
Depends on the app you write. Of course you always need to check the return value of malloc(). However, handling OOM gracefully only makes sense in very cases, such as low-level crucial system services, or when writing a library that might be used be them. Having a malloc wrapper that aborts on OOM is hence very common in many apps and frameworks. Often those wrappers are named xmalloc() or similar.
GLib's g_malloc() is aborting, too.
RE: What is the correct way to handle "out of memory"? - asymptote697 - 07-26-2023
### Follow the standardized API ###
Even on Linux, ulimit can be used to get a prompt malloc error return. It's just that it defaults to unlimited.
There is a definite pressure to conform to published standards. On most systems, in the long run, and eventually even on Linux, [`malloc(3)`](
[To see links please register here]
) will return a correct indication of failure. It is true that desktop systems have virtual memory and demand paging, but even then not checking [`malloc(3)`]([To see links please register here]
) only works in a debugged program with no memory leaks. If anything goes wrong, someone will want to set a [`ulimit`]([To see links please register here]
) and track it down. Suddenly, the `malloc` check makes sense.RE: What is the correct way to handle "out of memory"? - carlinghergvwecq - 07-26-2023
If you are going to handle huge amounts of memory, and want to make statements to Linux like "now I have memory area ABC and I don't need the B piece, do as you wish", have a look to mmap()/madvise() family of functions available in stock GNU C library. Depending on your usage patterns, the code can end up even simpler than using malloc. This API can also be used to help Linux not waste memory by caching files you are going to read/write only once.
They are nicely documented in GNU libc info documentation.
RE: What is the correct way to handle "out of memory"? - gambetta397 - 07-26-2023
It depends on the type of application that you are working on. If the application does work that is divided into discrete tasks where an individual task can be allowed to fail, then checking memory allocations can be recovered from gracefully.
But in many cases, the only reasonable way to respond to a malloc failure is by terminating the program. Allowing your code to just crash on the inevitable null dereference will achieve that. It would certainly always be better to dump a log entry or error message explaining the error, but in the real world we work on limited schedules. Sometimes the return on investment of pedantic error handling isn't there.
RE: What is the correct way to handle "out of memory"? - overextraction889302 - 07-26-2023
It is usually impossible for a program to handle running out of memory. What are you going to do? Open a file and log something? If you try to allocate a large block and it fails, you may have a fallback and try again with a smaller buffer, but if you fail to allocate 10 bytes, there is not much you can do. And checking for null constantly convolutes the code. For that reason I usually add a custom function that does checking and aborts on fail:
```c
static void* xmalloc(size_t sz) {
void* p = malloc(sz);
if (!p) abort();
return p;
}
```