This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Intermittent cygwin heap allocation problem


Dave Korn wrote:
> Cliff Hones wrote:
>>          6 [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 98
>>[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.
> 
>   Sometimes, when a dll is loaded in a forked child, the allocated block ends
> higher up in memory than it did in the parent, and when that happens, it
> forces the next dll to be loaded to end up at a much higher base address.
> I've spent a good deal of time looking at it in the past but it's fairly
> obscure.  I should probably have another go at it.
> 
>   (I can see how applications that LoadLibrary a new .dll after they've
> already been running for a long time and allocated lots of heap might be
> particularly prone to these remapping failures too).

I'm not sure I understand what you're saying here.  The parent (the bash
shell) has been running (and idle) a long time, but the new child which
is being forked is presumably a new windows process.  The error relates to
the virtual mapping in the new process, so Windows appears to be allocating
DLLs or their info blocks at different addresses during the initialisation of
two new processes, both started by the same (old) bash process.

I also find the sleep(2000) in heap.cc when the mapping error is detected
rather suspicious - is this to avoid a race condition with the parent?

>   Fortunately, the 'Just try again' workaround almost always works.

Since the error seems to be reliably detected by both parent and child, if
this strange allocation by windows is often transitory, there could be
a workaround: if a fork fails in this way, try it (once) more.

-- 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]