Christopher Faylor wrote: > On Wed, Jan 18, 2006 at 03:16:27PM -0000, Dave Korn wrote: > >>Cliff Hones wrote: >> >>>[main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate >>>heap, Win32 error 487, base 0x480000, top 0x4A0000, reserve_size 126976, >>>allocsize 131072, page_const 4096 >>>[main] bash 2160 child_copy: stack write copy failed, 0x22E960..0x230000, >>>done 0, windows pid 2287764, Win32 error 5 bash: fork: No error >> >>>appreciate useful suggestions of how best to do this). Looking at the >>>Cygwin source, I see that the error is caused by Windows VirtualAlloc >>>responding with Invalid Address error, yet the area being allocated >>>(base 480000, top 4a0000, size 128MB) looks ok to me. Am I right in >>>thinking this means Windows thinks (part of) this area is already in >>>use in the forkee? >> >> >>It is, as you guessed, already in use. >> >>It relates to the little bit of extra data that cygwin keeps in memory >>allocated immediately after each .dll that is loaded in an image. >> >>The code that allocates these is flexible, and if it can't allocate >>space immediately after the dll it will work its way up in memory until >>it succeeds. > > > Actually, this kind of error is more likely to be caused by a thread starting > prior to cygwin initialization and grabbing cygwin's heap area to use for its > stack. I moved things around a bit in 1.5.19 to try to avoid that but I guess > it was for naught.
Can this explain failures to initialize executables which don't use threads? I don't know, but I wouldn't have thought 'ls' uses threads. -- Cliff -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
