X-Spam-Check-By:	sourceware.org
Message-ID:	<43CE6718.7080205@hones.org.uk>
Date:	Wed, 18 Jan 2006 16:04:40 +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:	<SERRANOdcx3Vp20N39x000001b5 AT SERRANO DOT CAM DOT ARTIMI DOT COM>
In-Reply-To:	<SERRANOdcx3Vp20N39x000001b5@SERRANO.CAM.ARTIMI.COM>
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

Dave Korn wrote:
> Cliff Hones wrote:
>>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. 
> 
>   Nope.  The mismatch is between the parent and the child, not between two
> children.  However you're right about the problem relating to things being
> mapped to different addresses in the two.

Yes - I know the mismatch is between parent and child.  I was referring to the
fact that when you try again the invocation of the second child works, so
Windows is presumably doing something different, though presumably the
parent (bash) started both in exactly the same way.

>   When I was investigating, I found cases where the .dll was mapped at the
> exact same base address, but for some reason the trailing info block had been
> allocated higher up in memory in the child than the parent, and it had crossed
> over a granularity boundary and therefore forced the /next higher/ dll to be
> loaded 64k above the position it had occupied in the parent.

Odd.  I'm not familiar with the info block - maybe I'll take a look.

>>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?
> 
>   Dunno, suspect it may have been something experimental.  Take a look at when
> it arrived in the CVS and check the associated changelog entry.

Aha - only just added (Boxing day!) and something to do with ctrl/c problems.
I'm not sure how it helps, but it's not relevant to the problem I'm seeing.

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

- Raw text -