c++embeddedwindows-cenew-operatorviper

Dynamic Memory Allocation Failure Recovery


I'm working on an embedded processor (400 MHz Intel PXA255 XScale), and I thought I saw one case where there wasn't enough memory to satisfy a 'new' operation. The program didn't crash, so I assumed other threads had freed their memory and it was just a transient thing. This is some pretty critical code, so exiting is not an option, and some sort of error needs to be returned to the remote user.

Would the following small fix be enough to solve the problem, or is there a better way? Before replacing every 'new' with the following code, I thought I'd ask.

char someArr[];
do{ 
    someArr = new char[10]; 
    Sleep(100); // no justification for choosing 100 ms
} while ( someArr == NULL );

Does the Sleep help? Should I set some max number of retries? Is it possible to use static initialization everywhere?

FINAL UPDATE: Thank you very much for the helpful responses, but it turns out there was an error in the code checking for failed memory allocation. I will keep all of these answers in mind, and replace as many malloc's and new's as I can, though (especially in error-handling code).


Solution

  • There are a few different ways to attack this - note that the tool instructions will vary a bit, based on what version of Windows CE / Windows Mobile you are using.

    Some questions to answer:

    1. Is your application leaking memory, leading to this low memory condition?

    2. Does your application simply use too much memory at certain stages, leading to this low memory condition?

    1 and 2 can be investigated using the Windows CE AppVerifier tool, which can provide detailed memory logging tools for your product. Other heap wrapping tools can also provide similar information (and may be higher-performance), depending on your product design.

    http://msdn.microsoft.com/en-us/library/aa446904.aspx

    3. Are you allocating and freeing memory very frequently in this process?

    Windows CE, prior to OS version 6.0 (don't confuse with Windows Mobile 6.x) had a 32MB / process virtual memory limit, which tends to cause lots of fun fragmentation issues. In this case, even if you have sufficient physical memory free, you might be running out of virtual memory. Use of custom block allocators is usually a mitigation for this problem.

    4. Are you allocating very large blocks of memory? (> 2MB)

    Related to 3, you could just be exhausting the process virtual memory space. There are tricks, somewhat dependent on OS version, to allocate memory in a shared VM space, outside the process space. If you are running out of VM, but not physical RAM, this could help.

    5. Are you using large numbers of DLLs?

    Also related to 3, Depending on OS version, DLLs may also reduce total available VM very quickly.

    Further jumping off points:

    Overview of CE memory tools

    http://blogs.msdn.com/ce_base/archive/2006/01/11/511883.aspx

    Target control window 'mi' tool

    http://msdn.microsoft.com/en-us/library/aa450013.aspx