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
来源:https://stackoverflow.com/questions/8370264/malloc-returns-null-and-sets-errno-to-enomem-but-there-is-plenty-of-heap-space