Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Reply-To:	<nhv AT cape DOT com>
From:	"Norman Vine" <nhv AT cape DOT com>
To:	"'Robert Collins'" <robert DOT collins AT itdomain DOT com DOT au>,
	"'Charles Wilson'" <cwilson AT ece DOT gatech DOT edu>,
	"'Jason Tishler'" <jason AT tishler DOT net>
Cc:	"'Michael Hudson'" <mwh AT python DOT net>,
	<david_abrahams AT users DOT sourceforge DOT net>,
	"'Cygwin'" <cygwin AT sources DOT redhat DOT com>
Subject:	RE: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
Date:	Fri, 7 Dec 2001 20:32:07 -0500
Message-ID:	<003001c17f88$26a03d40$a300a8c0@nhv>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook 8.5, Build 4.71.2232.26
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4522.1200
Importance:	Normal
In-Reply-To:	<01fc01c17f74$0d774a20$0200a8c0@lifelesswks>

Robert Collins writes:
>
>----- Original Message -----
>From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
>> > The above occurs during Cygwin's fork() when the Cygwin DLL cannot
>> > load a DLL to the same address in the child that it had in the parent.
>> > I have seen this during Python 2.1.1 regression tests with threads
>> > enabled.
>>
>>
>> Part of the problem may be that cyggdbm.dll was built with
>> --auto-image-base.  It was later demonstrated that this can cause
>> problems with fork; you're better off just letting ld assign the default
>> dllbase, which means that EVERY process will remap the dll at runtime.
>> Thus, no hardcoded conflicts.  Downside: *very* slightly delay in
>> loading DLLs -- probably unnoticeable.
>>
>> (Did I get that right, robert?)
>
>Yes. There is actually a longer term solution... which is to 'rebase'
>every cygwin linked .dll on a particular system to not conflict with
>each other - which has to be done by setup.exe.

FWIW
I just tried patching Cygwin's dlopen() function to always rebase dll's
on loading with a 'slightly hacked to force rebasing' version of
niftyload.cpp
< available from http://thecodeproject/dll/niftyload.asp >
and got the same errors as Jason reported in his original message.

  C:\home\jtishler\src\PythonCvs\nothreads\python.exe: *** unable to remap
C:\cygwin\bin\cygssl.dll to same address as parent -- 0x1A2F0000
          0 [main] python 852 sync_with_child: child 2772(0x158) died before
initialization with status code 0x1
        996 [main] python 852 sync_with_child: *** child state child loading
dlls
    Traceback (most recent call last):
      File "test2.py", line 4, in ?
        pid = os.fork()
    OSError: [Errno 11] Resource temporarily unavailable

The author of the code states that the base address is chosen the wrong way.
"Rebased dll's should start from the top of address space and work down"

BTW
If it isn't obvious I know next to nothing about dll rebaseing issues

Cheers

Norman


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

- Raw text -