http://bugs.winehq.org/show_bug.cgi?id=20986 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net --- Comment #37 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.