X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Intermittent cygwin heap allocation problem
Date: Wed, 18 Jan 2006 15:16:27 -0000
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <43CE4834.1010702@hones.org.uk>
Message-ID: <SERRANOgjHXwKHvyo3D000001af@SERRANO.CAM.ARTIMI.COM>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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).

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


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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