I have a situation in which malloc() returns NULL and sets errno to ENOMEM. But the CRT heap (which is growable) has plenty of memory to work with. At the time of malloc, my process memory is about 900 MB. The host process is a Java executable executed under the Sun HotSpot JVM.
The malloc() I'm doing is 80 megabytes, and fails. If I do a 60 MB allocation, it succeeds. After that, a 50 MB allocation, followed by another one, and another one also succeed: clearly, I still have a lot of memory left but the 80 MB malloc seems too "big" to digest for the OS.
I'm using Windows 7 x64 SP1 with 4 GB RAM. My process is a 32-bit process, built with VC++ 2010 SP1. I'm using the Low Fragmentation Heap, which is the default on Win 7 - I have also verified with HeapQueryInformation. The VC2010 C Run-Time that I am using creates the heap this way:
HeapCreate(0, BYTES_PER_PAGE, 0)
According to the documentation of HeapCreate, HeapAlloc will automatically call VirtualAlloc for blocks larger than 512KB.
What the heck can cause malloc() to fail if this is not a lack of memory? Is my memory too fragmented? I thought Windows would compact the heap automatically.
This is really weird, I have never seen this behavior before.
Another computer with Windows XP SP3 32-bit is exhibiting the same behavior.
Thanks, Martin