Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Tue, 18 Sep 2001 22:33:07 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [BUG] cygwin-1.3.3-2 -- making auto-import dlls
Message-ID: <20010918223307.E8924@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F197 AT itdomain002 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F197@itdomain002.itdomain.net.au>
User-Agent: Mutt/1.3.21i

On Wed, Sep 19, 2001 at 12:34:51PM +1000, Robert Collins wrote:
>I went round this one with Paul's original patch.
>
>Auto image base is bad (for cygwin).
>
>Very bad.
>
>Ok, now the scare is over, here is why:
>
>Lemma: Cygwin1.dll is only relocatable if it is consistently relocated
>to the same address in _all_ process's that load cygwin1.dll. Proof:
>cygwin copies the process address space to fork, if references to
>cygwin1.dll are not valid in the hild, the child will die badly.
>
>Auto image base will conflict with cygwin1.dll semi-randomly. Because
>other cygwin linked .dll's come before cygwin1.dll in the PE header
>(don't know if this is due to link order, sorting of the file or
>whathaveyou) cygwin1.dll is the last .dll. Thus when there is a
>conflict, cygwin1.dll gets relocated.
>
>The problem: bash does not depend on these conflicting .dll's, so every
>process started that does depend on them will fail to initialise.
>
>Solution: don't use auto-image-base. The overhead from relocation is
>quite low, why not let windows just do its thing.

Even that is not guaranteed to fix this problem, though.

Location of the cygwin heap is one of a few AFAIK inavoidable iffy
assumptions that cygwin makes.  Cygwin's whole fork algorithm relies
on similar undocumented deterministic behavior.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/