C++/Windows: How to report an out-of-memory exception (bad_alloc)?

Question

Hi,

I'm currently working on an exception-based error reporting system for Windows MSVC++ (9.0) apps (i.e. exception structures & types / inheritance, call stack, error reporting & logging and so on).

My question now is: how to correctly report & log an out-of-memory error?

When this error occurs, e.g. as an bad_alloc thrown by the new op, there may be many "features" unavailable, mostly concerning further memory allocation. Normally, I'd pass the exception to the application if it has been thrown in a lib, and then using message boxes and error log files to report and log it. Another way (mostly for services) is to use the Windows Event Log.
The main problem I have is to assemble an error message. To provide some error information, I'd like to define a static error message (may be a string literal, better an entry in a message file, then using FormatMessage) and include some run-time info such as a call stack.
The functions / methods necessary for this use either

• STL (std::string, std::stringstream, std::ofstream)
• CRT (swprintf_s, fwrite)
• or Win32 API (StackWalk64, MessageBox, FormatMessage, ReportEvent, WriteFile)

Besides being documented on the MSDN, all of them more (Win32) or less (STL) closed source in Windows, so I don't really know how they behave under low memory problems.

Just to prove there might be problems, I wrote a trivial small app provoking a bad_alloc:

int main()
{
    InitErrorReporter();  

    try
    {
        for(int i = 0; i < 0xFFFFFFFF; i++)
        {
            for(int j = 0; j < 0xFFFFFFFF; j++)
            {
                char* p = new char;
            }
        }
    }catch(bad_alloc& e_b)
    {
        ReportError(e_b);
    }

    DeinitErrorReporter();

    return 0;
}

Ran two instances w/o debugger attached (in Release config, VS 2008), but "nothing happened", i.e. no error codes from the ReportEvent or WriteFile I used internally in the error reporting. Then, launched one instance with and one w/o debugger and let them try to report their errors one after the other by using a breakpoint on the ReportError line. That worked fine for the instance with the debugger attached (correctly reported & logged the error, even using LocalAlloc w/o problems)! But taskman showed a strange behaviour, where there's a lot of memory freed before the app exits, I suppose when the exception is thrown.

Please consider there may be more than one process [edit] and more than one thread [/edit] consuming much memory, so freeing pre-allocated heap space is not a safe solution to avoid a low memory environment for the process which wants to report the error.

Thank you in advance!

Answer 1

"Freeing pre-allocated heap space...". This was exactly that I thought reading your question. But I think you can try it. Every process has its own virtual memory space. With another processes consuming a lot of memory, this still may work if the whole computer is working.

Answer 2

Please consider there may be more than one process consuming much memory, so freeing pre-allocated heap space is not a safe solution to avoid a low memory environment for the process which wants to report the error.

Under Windows (and other modern operating systems), each process has its own address space (aka memory) separate from every other running process. And all of that is separate from the literal RAM in the machine. The operating system has virtualized the process address space away from the physical RAM.

This is how Windows is able to push memory used by processes into the page file on the hard disk without those processes having any knowledge of what happened.

This is also how a single process can allocate more memory than the machine has physical RAM and yet still run. For instance, a program running on a machine with 512MB of RAM could still allocate 1GB of memory. Windows would just couldn't keep all of it in the RAM at the same time and some of it would be in the page file. But the program wouldn't know.

So consequently, if one process allocates memory, it does not cause another process to have less memory to work with. Each process is separate.

Each process only needs to worry about itself. And so the idea of freeing a pre-allocated chunk of memory is actually very viable.

Answer 3

You can't use CRT or MessageBox functions to handle OOM since they might need memory, as you describe. The only truly safe thing you can do is alloc a chunk of memory at startup you can write information into and open a handle to a file or a pipe, then WriteFile to it when you OOM out.

Answer 4

Summing up some comments & research, I first take down some info about memory to be able to explain some approach I found.

There are three kinds of things people use to call "memory":

• Virtual memory (when wrongly used for "virtual address space")
• heap space (that is either physical RAM space or page file space)
• (real) physical memory space

When you use new (or HeapAlloc or VirtualAlloc with MEM_COMMIT), the OS reserves a virtual address range, allocates heap space and maps both.
You can use AWE (e.g. AllocateUserPhysicalPages) to allocate physical memory w/o mapping it to a virtual address range (use VirtualAlloc with MEM_RESERVE | MEM_PHYSICAL to make up for the mapping).

Now, to take some advantages from this, I'm sorry i need to go into detail and unfortunately write a lot of text on this memory topic. I tried to point out the important things using bold print.

---

Possible approaches in out-of-memory conditions to log / report an error:

• You cannot rely on CRT or STL to behave "correctly" under out-of-memory conditions.
• You can pre-allocate a chunk of memory (that is, virtual memory / adress space & physical / page file memory) and use it for buffers
• You cannot (simply) pre-allocate a chunk of memory and free it to provide free memory to CRT and other functions, since freed memory (= physical memory) can be allocated by every thread and process
• You can use HeapLock (Win32) to prevent other threads of your current process from allocating / deallocating heap space
• There are at least two heaps in your app: the process's heap (GetProcessHeap()) and the CRT heap (_get_heap_handle())
• the standard new operator internally uses HeapAlloc on the CRT heap (!)
• memory is split into pages, you can determine their size with GetSystemInfo(), dwPageSize
• You can allocate whole pages of physical memory (w/o virtual memory mapping) using AWE (AllocateUserPhysicalPages, VirtualAlloc to reserve address space, MapUserPhysicalPages)
• You can use HeapReAlloc with HEAP_REALLOC_IN_PLACE_ONLY to re-size an allocated chunk of memory

---

Now, my approach: [note: I edited it to work with HeapReAlloc and only one buffer]

• If you just need some buffers to work with, use either stack space global/static variables (.BSS / .DATA / ...) in your c++ program or pre-allocated heap space (even better: pre-allocated physical memory -> AWE). Stack space Global/static variables are probably a better idea since they're part of your .EXE and therefore do not need to be allocated (-> no exceptions)
• If you have to use CRT / STL / Win32 functions, you have to make sure they a) do not require heap space or b) there is enough heap space available

Of course, the trick is to provide heap space to CRT / ... functions when an out-of-memory condition appears (indicated by an bad_alloc, for example). They internally use malloc / HeapAlloc, that means they try to allocate heap space and reserve a virtual address range. So, if you have only some pre-allocated buffers, you had to prevent further memory allocation and remap their allocation requests to your pre-defined buffer. You could make use of _set_new_handler and / or overwrite the global new op, but for me, this didn't work (std::string yet called the normal new).
So, if you cannot redirect allocation queries, you have to provide free physical memory (or at least heap space) that can only be allocated by your process (= that is locked for other processes)! To do this, you could make use of the (physical!) memory layout AFAIK, i.e. that the physical memory is split into pages. Consider the following approach:

1. When initialising you error reporter, (if you have more than one thread already running), lock the heap and pre-allocate a a chunk of memory at the size of one memory page; make sure it's aligned to a page and does not cover two pages.
2. Unlock the heap and begin to work (don't forget to use a try-catch!).
3. When catching the bad_alloc, do not try to use CRT or STL or whatever functions you don't know the code of. Of course, do not try to allocate memory.
4. In your error handler, lock the heap and resize your pre-allocated buffer in place.
5. You now have exactly that size you freed to work with; you can use STL or CRT functions if they do not exceed the free heap space.
6. Don't forget to unlock the heap!

All of it relys on HeapAlloc and HeapReAlloc: When you allocate a whole memory page and later re-allocate it in place (resize it), you still should have that page reserved, but with free space on it.

In code, it's something like:

SYSTEM_INFO sSysInfo;
GetSystemInfo(&sSysInfo);

HANDLE hCRTHeap = (HANDLE)_get_heap_handle();
BYTE* pcBackupBuffer = (BYTE*)HeapAlloc(hCRTHeap, 0, sSysInfo.dwPageSize - 1);

try
{
    for(size_t i = 0; i < 0xFFFFFFFF; i++)
    {
        BYTE* pc = new BYTE[32];
    }
    printf("NO bad_alloc thrown at the for loop\r\n");
}catch(bad_alloc&)
{
    printf("bad_alloc thrown at the for loop\r\n");
}

try
{
    BYTE* test = new BYTE[32];
    printf("NO bad_alloc thrown at the first test\r\n");
}catch(bad_alloc&)
{
    printf("bad_alloc thrown at the first test\r\n");
}

/*pcBackupBuffer = */HeapReAlloc(hCRTHeap, HEAP_REALLOC_IN_PLACE_ONLY, pcBackupBuffer, 1);

try
{
    BYTE* test = new BYTE[200];
    printf("NO bad_alloc thrown at the second test\r\n");
}catch(bad_alloc&)
{
    printf("bad_alloc thrown at the second test\r\n");
}

---

Output:

bad_alloc thrown at the for loop
bad_alloc thrown at the first test
NO bad_alloc thrown at the second test

On Vista x64, VS 2008, x86 Debug, after allocating approx. 2.069.692 K RAM (says taskman). Should be out-of-virtual-address-space exceptions.
Further testing with 2 instances, enhanced code (enhanced output and tests), build against x64 / Release w/o debugger attached, 4 GB RAM + max. 2 GB page file showed similar behaviour concerning the HeapReAlloc feature. Just some strange behaviour: Even after throwing a bad_alloc, sometimes an equal allocation (some lines below) still works w/o exception o.O

Some words about the sizeing:

• I used the BYTE[32] in the for loop because the new op actually allocates a bit more (in debug mode) than the size passed as parameter, and I wanted to allocate each possible mem page so that the first test will really fail (and allocating only one byte each time is really sloooow)
• the second test fails allocating more memory than freed, I don't know exactly why. Maybe the page was filled up with the BYTE[32] from the for loop, so I've to figure out the exact amount to allocate from the page of pcBackupBuffer

It's all kind of a dirty hack, so I have to admit: use this only in special (emergency ^^) cases and do not to rely on it. But you might get 3 or 4 K of memory, and even get further semi-pages repeating this trick. I think that might be enough for simple CRT / Win32 / STL functions to operate on.

Answer 5

• pre-allocate the buffer(s) you need
• link statically and use _beginthreadex instead of CreateThread (otherwise, CRT functions may fail) -- OR -- implement the string concat / i2a yourself
• Use MessageBox (MB_SYSTEMMODAL | MB_OK) MSDN mentions this for reporting OOM conditions (and some MS blogger described this behavior as intended: the message box will not allocate memory.)

Logging is harder, at the very least, the log file needs to be open already.

Probably best with FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH, to avoid any buffering attempts. The first one requires that writes and your memory buffers are sector aligned (i.e. you need to query GetDiskFreeSpace, align your buffer by that, and write only to "multiple of sector size" file offsets, and in blocks that are multiples of sector size. I am not sure if this is necessary, or helps, but a system-wide OOM where every allocation fails is hard to simulate.