What to do when an out-of-memory error occurs? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

What's the graceful way of handling out of memory situations in C/C++?

Hi,

this seems to be a simple question a first glance. And I don't want to start a huge discussion on what-is-the-best-way-to-do-this....

Context: Windows >= 5, 32 bit, C++, Windows SDK / Win32 API

But after asking a similar question, I read some MSDN and about the Win32 memory management, so now I'm even more confused on what to do if an allocation fails, let's say the C++ new operator.

So I'm very interested now in how you implement (and implicitly, if you do implement) an error handling for OOM in your applications.

If, where (main function?), for which operations (allocations) , and how you handle an OOM error.

(I don't really mean that subjectively, turning this into a question of preference, I just like to see different approaches that account for different conditions or fit different situations. So feel free to offer answers for GUI apps, services - user-mode stuff ....)

Some exemplary reactions to OOM to show what I mean:

• GUI app: Message box, exit process
• non-GUI app: Log error, exit process
• service: try to recover, e.g. kill the thread that raised an exception, but continue execution
• critical app: try again until an allocation succeeds (reducing the requested amount of memory)
• hands from OOM, let STL / boost / OS handle it

Thank you for your answers!

The best-explained way will receive the great honour of being an accepted answer :D - even if it only consists of a MessageBox line, but explains why evering else was useless, wrong or unneccessary.

Edit: I appreciate your answers so far, but I'm missing a bit of an actual answer; what I mean is most of you say do开发者_JAVA百科n't mind OOM since you can't do anything when there's no memory left (system hangs / poor performance). But does that mean to avoid any error handling for OOM? Or only do a simple try-catch in the main showing a MessageBox?

---

On most modern OSes, OOM will occur long after the system has become completely unusable, since before actually running out, the virtual memory system will start paging physical RAM out to make room for allocating additional virtual memory and in all likelihood the hard disk will begin to thrash like crazy as pages have to be swapped in and out at higher and higher frequencies.

In short, you have much more serious concerns to deal with before you go anywhere near OOM conditions.

Side note: At the moment, the above statement isn't as true as it used to be, since 32-bit machines with loads of physical RAM can exhaust their address space before they start to page. But this is still not common and is only temporary, as 64-bit ramps up and approaches mainstream adoption.

Edit: It seems that 64-bit is already mainstream. While perusing the Dell web site, I couldn't find a single 32-bit system on offer.

---

You do the exact same thing you do when:

• you created 10,000 windows
• you allocated 10,000 handles
• you created 2,000 threads
• you exceeded your quota of kernel pool memory
• you filled up the hard disk to capacity.

You send your customer a very humble message where you apologize for writing such crappy code and promise a delivery date for the bug fix. Any else is not nearly good enough. How you want to be notified about it is up to you.

---

Basically, you should do whatever you can to avoid having the user lose important data. If disk space is available, you might write out recovery files. If you want to be super helpful, you might allocate recovery files while your program is open, to ensure that they will be available in case of emergency.

---

Simply display a message or dialog box (depending on whether your in a terminal or window system), saying "Error: Out of memory", possibly with debugging info, and include an option for your user to file a bug report, or a web link to where they can do that.

If your really out of memory then, in all honesty, there's no point doing anything other than gracefully exiting, trying to handle the error is useless as there is nothing you can do.

---

In my case, what happens when you have an app that fragments the memory up so much it cannot allocate the contiguous block needed to process the huge amount of nodes?

Well, I split the processing up as much as I could.

For OOM, you can do the same thing, chop your processes up into as many pieces as possible and do them sequentially.

Of course, for handling the error until you get to fix it (if you can!), you typically let it crash. Then you determine that those memory allocs are failing (like you never expected) and put a error message direct to the user along the lines of "oh dear, its all gone wrong. log a call with the support dept". In all cases, you inform the user however you like. Though, its established practice to use whatever mechanism the app currently uses - if it writes to a log file, do that, if it displays an error dialog, do the same, if it uses the Windows 'send info to microsoft' dialog, go right ahead and let that be the bearer of bad tidings - users are expecting it, so don't try to be clever and do something else.

---

It depends on your app, your skill level, and your time. If it needs to be running 24/7 then obviously you must handle it. It depends on the situation. Perhaps it may be possible to try a slower algorithm but one that requires less heap. Maybe you can add functionality so that if OOM does occur your app is capable of cleaning itself up, and so you can try again.

So I think the answer is 'ALL OF THE ABOVE!', apart from LET IT CRASH. You take pride in your work, right?

Don't fall into the 'there's loads of memory so it probably won't happen' trap. If every app writer took that attitude you'd see OOM far more often, and not all apps are running on a desktop machines, take a mobile phone for example, it's highly likely for you to run into OOM on a RAM starved platform like that, trust me!

If all else fails display a useful message (assuming there's enough memory for a MessageBox!)