rob at codeweavers.com
Sat Jan 15 15:58:30 CST 2005
Oliver Stieber wrote:
>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.
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.
More information about the wine-devel