Q HeapAlloc.

[Rob Shearman]

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