Do you handle Out-Of-Memory conditions?

Question

What do you do when malloc returns 0 or new throws exception? Just halt or try to survive OOM condition/save the user's work?

Answer 1

I'd avoid the OOM like avoiding a crash.

Avoid doing huge chunk of work (and allocate huge chunk of memory) at once. Keep the data on the disk, trust the OS disk cache and make use of memory-mapped IO as much as possible, and only operate on a small part of data at a time. If large amounts of data need to be on-line (served with low latency) then keep them in the memory across several machines, like all the big search engine companies do. Or buy a SSD.

Answer 2

Most people answering this question have probably never worked on embedded systems, where malloc returning 0 is a very real possibility. On a system I'm currently working on, there is a total of 4.25K bytes of RAM (that's 4352 bytes). I'm allocating 64 bytes for the stack, and currently have a 1600 byte heap. Just yesterday I was debugging a heap walk routine so I can follow the allocation and freeing of memory. The heap walk uses a small (30 byte) statically allocated buffer to output to a serial port. It will be turned off for the release version.

Since this is a consumer product, it better not run out of memory once the product has been released. I'm sure it will during development. In any case, about all I can do is beep the speaker a couple of times, and force a reboot.

Answer 3

To be fairly honest, in all projects I've done (keep in mind I'm not working anywhere yet), I've never considered that it could happen, and thus I suppose my programs would die a very fast death.

Besides, handling an OOM requires you to have preallocated the resources to display the error message or to save everything, which can be kind of inconvenient.

I feel that these days, memory costing less than peanuts, it's not something that should happen frequently. On the dawn of protected memory and before, maybe that was a concern, but now? The only OOM errors I've ever seen were from bugged code.

Answer 4

Checking malloc return codes is usuall pointless anyway.

Modern operating systems overcommit memory: They give processes more memory than is actually available. The memory your process is granted is virtual, all mapped to a single zeroed-out page.

It's not until you write to the memory that a physical, unique, page is allocated for your processes. If this allocation fails the kernel will terminate a process (perhaps yours!) in an attempt to find memory. At that point there's nothing you can do any more.

Answer 5

Unless you're developing for embedded systems, real-time systems, or systems that are so critical that failures can cost lives, or billions of dollars... Then it's probably not financially worth it to worry about out of memory conditions.

In most cases, there is little that can be done when you are out out of memory anyways, since there is no memory to create any new objects or perform any tasks that may do something. You have to weigh the cost of the app handling OOM versus the benefit you get from doing it.

Answer 6

I would always check for error. If something returns an error condition, then it has to be handled by your program. Even if it is a message that says "Out of memory, gotta go!", it is better than "Access violation", "core dumped", or whatever. One is an error condition you handle, the other is a bug. And the user will perceive it as such as well.

For your specific case, you could try to roll back the operation, freeing resources that you've allocated until reaching the point of failure, reporting the error, and continuing execution (maybe when you are trying to quit the application, you can give the option to exit immediately). This way, the user can decide what to do, or try to free up some memory by fiddling around, closing files, etc. Of course, how you can handle the situation is highly dependent on your program - a program that is not supposed to be interactive probably just needs to log the error and either quit, or continue.