c++ bad_alloc exception not catched

Question

I have following code to allocate a huge amount of data and if it is more than there is memory available (here it is 32GB) it should throw an exception. Using:

bool MyObject::init()
{    
    char* emergency_memory = new char[32768];
    try
    {
        std::vector<std::vector<MyData> > data_list;
        std::vector<MyData> data;
        data.resize(1000);

        for(size_t i=0; i<1000; i++)
        {
           data_list.push_back(data);
           data_list.push_back(data);
        }       
    }
    catch (const std::bad_alloc& e)
    {
        delete[] emergency_memory;        
        std::cout << "Data Allocation failed:" << e.what() << std::endl;
        return false;
    }
    return true;
}

The exception is never caught. The application just terminates, or crashes the operating system.

What did I do wrong?

Answer 1

Your new operator has to get the memory from somewhere. As new is user space code that has no connection to real memory whatsoever, all that it can do is to ask the kernel via the syscall sbrk() or the syscall mmap() for some memory. The kernel will respond by mapping some additional memory pages into your process's virtual address space.

As it happens, any memory pages that the kernel returns to user processes must be zeroed out. If this step were skipped, the kernel might leak sensible data from another application or itself to the userspace process.

Also it happens, that the kernel always has one memory page that contains only zeros. So it can simply fulfill any mmap() request by simply mapping this one zero page into the new address range. It will mark these mapping as Copy-On-Write, so that whenever your userspace process starts writing to such a page, the kernel will immediately create a copy of the zero page. It is then that the kernel will grope around for another page of memory to back its promises.

You see the problem? The kernel does not need any physical memory up unto the point where your process actually writes to the memory. This is called memory over-committing. Another version of this happens when you fork a process. You think the kernel would immediately copy your memory when you call fork()? Of course not. It will just do some COW-mappings of the existing memory pages!

(This is an important optimization mechanism: Many mappings that are initiated never need to be backed by additional memory. This is especially important with fork(): This call is usually immediately followed by an exec() call, which will immediately tear down the COW-mappings again.)

The downside is, that the kernel never knows how much physical memory it actually needs until it fails to back its own promises. That is why you cannot rely on sbrk() or mmap() to return an error when you run out of memory: You don't run out of memory until you write to the mapped memory. No error code return from the syscall means that your new operator does not know when to throw. So it won't throw.

What happens instead is that the kernel will panic when it realizes that it has run out of memory, and start shooting down processes. That is the job of the aptly named Out-Of-Memory killer. That's just to try to avoid rebooting immediately, and, if the heuristics of the OOM-killer work well, it will actually shoot the right processes. The killed processes won't get so much as a warning, they are simply terminated by a signal. No user-space exception involved, again.

---

TL;DR: Catching bad_alloc exceptions on an over-committing kernel is next to useless.

Answer 2

Linux overcommits memory. This means that malloc() does not really allocate, it only makes the process to believe it does. The actual allocation happens when a memory page is really needed, after a page-fault. For that reason, malloc() does not fail even if it needs to allocate more memory than is actually available.

I have tested your code, and it also crashes on my Linux. To actually have a bad_alloc exception, one can simply disable overcommitting.

This is described in detail in Virtual memory settings in Linux - The Problem with Overcommit .

Disabling overcommitting works for me:

sudo sh -c 'echo 2 > /proc/sys/vm/overcommit_memory'

This setting has two drawbacks. There will be more cases when malloc() returns NULL, even though it used to work before this setting. The second drawback is that this is not persistent, and gets back to the original value after reboot. For that, you need to update the boot scripts.

EDIT: To make it work after reboot you can sudo vi /etc/crontab (see man 5 crontab) and then add the line

@reboot     root echo 2 > /proc/sys/vm/overcommit_memory

Answer 3

bad_alloc will throw if the malloc fails, and the malloc will fail if the kernel call for more memory fails. In the case of Linux, the kernel will commonly let the process succeed in taking more memory, and then if Linux feels like a process is hogging to much memory, it'll just kill it. This is different than if Linux simply denied more memory to the process, which would cause a well-formed bad_alloc.

The solution would be to override new/delete (Which are simple malloc/free calls and a check for malloc == 0), to functions that also keep track of memory usage. Then, new could throw bad_alloc when memory usage is too high, before Linux unceremoniously kills it.