RE: Intermittent cygwin heap allocation problem

["Dave Korn" <dave dot korn at artimi 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/