X-Spam-Check-By: sourceware.org
Message-ID: <43CE6A41.8050208@hones.org.uk>
Date: Wed, 18 Jan 2006 16:18:09 +0000
From: Cliff Hones <cliff AT hones DOT org DOT uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Intermittent cygwin heap allocation problem
References: <43CE4834 DOT 1010702 AT hones DOT org DOT uk> <SERRANOgjHXwKHvyo3D000001af AT SERRANO DOT CAM DOT ARTIMI DOT COM> <20060118160845 DOT GA15870 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20060118160845.GA15870@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.5 (--)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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

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/