3

As far as I understand std::bad_alloc exceptions in C++ are triggered when the program runs out of memory. Is there a way to monitor how much memory left there are and trigger a special routine before we reach the point of no return ?

0x26res
  • 11,925
  • 11
  • 54
  • 108
  • 1
    you can catch the exception and call that special routine that frees some of your dynamic memory then. – moooeeeep Nov 05 '12 at 16:04
  • It's very system dependent, and also dependent on what caches the kernel can free up when needed. – Some programmer dude Nov 05 '12 at 16:04
  • In standard C++, the only way is to try to allocate a big array and then catch the `bad_alloc` exception. But in a multi-threaded program, the answer might change before you can make use of it... So you are actually asking the wrong question. – Nemo Nov 05 '12 at 16:06
  • @Nemo: what would be the right question? – 0x26res Nov 05 '12 at 16:12
  • "How do I handle running out of memory in C++?" For which Kerrek's answer is pretty good – Nemo Nov 05 '12 at 16:23

1 Answers1

5

No, but you can register a handler with std::set_new_handler, which the default implementation of the global operator new() executes in a loop until either the handler doesn't return or there is no further handler registered. The handler may itself try to free up some more memory, or post a log message, or something similar.

The specifics of how much memory are available for your allocation function depend very heavily on your platform and your operating system, though, so don't expect too much.

For example, on systems that oversubscribe memory, your allocations may succeed, but your program could still die because the system is out of memory.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • With overcommit, your program can just as well die even if it doesn't allocate memory, because some *other* process ate all the pies. – Steve Jessop Nov 05 '12 at 16:18
  • @SteveJessop: Ah yes, quite. I suppose the point is that on a normal desktop OS it's pretty difficult to incorporate system-wide memory management into your own application (and perhaps you should just not bother?). – Kerrek SB Nov 05 '12 at 16:22
  • @SteveJessop: Does the C++ spec allow "overcommit"? I do not think it does... Unless I missed it, nowhere does it allow your process to crash just because it touches some memory properly returned by `new`. Strictly speaking, Linux with overcommit enabled is not a conforming C++ platform. Or am I wrong? – Nemo Nov 05 '12 at 16:24
  • @Nemo: personally I think it's a bit dodgy, but I believe that officially it's outside the scope of the standard. An OS can kill a process at any time. The fact that it might do so *systematically* because of something the application does is what makes me think of it as dodgy, but AFAIK the committee has no complaint. I don't *think* the standard explicitly authorizes implementations to terminate processes due to stack overflow (in the main thread) either, and that's also systematically a consequence of program behavior. – Steve Jessop Nov 05 '12 at 16:29
  • 1
    The reason it's dodgy in my view is that the program might be carefully written to handle memory allocation failure and back off, or even to succeed using a slower algorithm that uses less memory like `std::stable_sort`. Or you might have implemented a garbage collector or cache-emptier that frees unnecessary memory when the `new_handler` is called. All of which effort is wasted because allocation never fails. From the programmer's POV this seems like a swindle. – Steve Jessop Nov 05 '12 at 16:32