http://bugs.winehq.org/show_bug.cgi?id=20986
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #37 from Anastasius Focht focht@gmx.net 2013-09-24 19:04:20 CDT --- Hello folks,
the failed allocation code can be found here:
http://git.savannah.gnu.org/cgit/gcl.git/tree/gcl/o/unexnt.c (_start -> recreate_heap)
The "maxima" application/executable was dumped/re-created using "unexec" from a win32 intermediate executable created by GCL compiler.
The hard-coded heap start/size limits indicate this (data_region_base, data_region_size, reserved_heap_size in .data section).
Failing VirtualAlloc():
--- snip --- 113E0000 ; Address = 113E0000 (heap_end) 2EC20000 ; Size = 784465920 (reserved_heap_size - committed_heap_size) 00002000 ; AllocType = MEM_RESERVE 00000001 ; Protect = PAGE_NOACCESS --- snip ---
It's not really clear from the GCL code why statically defined heap limits are really needed here (calculated at dump time). A runtime probe for large contiguous chunk to create/manage app heap should be fine. Sticking to specific win32 address space layout at dump time is somewhat silly.
Regards