Oliver Stieber wrote:
Hi, I been having a problem where HeapAlloc is failing even though there's plenty of virtual memory left
I've done a bit of digging but haven't been able to get to the bottom of it.
First of all I've checked that HeapAlloc will go into swap by allocating a lot of 64meg blocks and writing to them to force linux to allocate them properly, and it works fine.
Then I changed alloc.c so that CreateSubHeap writes the status returned by NtAllocateVirtualMemory and I get C00017 STATUS_NO_MEMORY. HEAP_CreateSubHeap Could not allocate 00410000 bytes reason: C00017 [STATUS_NO_MEMORY]
an I double checked this by putting a malloc in just after the failure, which failed.
So then I wrote a a small non-wine test program run as a seperate process to allocate ten times as much ram and ran it while just after the crash (while the debug box was still up) and it works fine.
Any ideas?
The most like answer is that there is so much fragmentation in your virtual address space that there is no block of contiguous memory free for whatever size is being passed into RtlCreateHeap. Inspecting /proc/<program PID>/maps will give you a clue as to how much fragmentation there is. Unfortunately, if this is your problem, there isn't a good solution to it. Windows is very good at keeping the virtual address space free by bunching all of the system DLLs up at just under the 2Gb barrier. The situation is worsened on Linux, due to prelink randomizing the address space, which is turned on on many modern Linux distros. However, I seem to remember there was a kernel patch written by Ingo Molnar that changes the way mmap and brk allocate virtual address space that could help a lot with this.
Rob