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:44:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <43CE6082.3070005@hones.org.uk>
Message-ID: <SERRANOdcx3Vp20N39x000001b5@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:
> Dave Korn wrote:

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

  I wasn't referring to your situation with bash in particular, this just
struck me as a side-issue that might cause the same problem.

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

  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.

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

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

  Yep, it might well work.  


    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/