Subject: Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
From: "Robert Collins" <[email-masked]>
To: "Jason Tishler" <[email-masked]>, "Cygwin" <[email-masked]>
Cc: "Michael Hudson" <[email-masked]>, <[email-masked]>
Date: Mon, 10 Dec 2001 23:42:01 +1100

Possibly because the cygwin heap is getting allocated across where those
.dll's would go.

Rob
===
----- Original Message -----
From: "Jason Tishler" <[email-masked]>
To: "Cygwin" <[email-masked]>
Cc: "Michael Hudson" <[email-masked]>;
<[email-masked]>
Sent: Monday, December 10, 2001 11:46 PM
Subject: Re: dll_list::load_after_fork() blues (was Re: [
python-Bugs-489709 ] Building Fails ...)

> On Sat, Dec 08, 2001 at 10:08:14AM +1100, Robert Collins wrote:
> > 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.
>
> I just tried a hand rebase of my system using the MS supplied rebase
> tool to see if this will fix the problem at least for the Python case.
> Specifically, I rebased the following DLLs:
>
>     o Python DLL (e.g., libpython2.2.dll)
>     o all Python standard shared extension modules (e.g., _socket.dll)
>     o all Cygwin DLLs in /usr/bin that match cyg*.dll except for the
>       following:
>
>           - cygwin1.dll: since I believe that it relies on being based
>             at 0x61000000
>           - cygcurl-2.dll: because it gets "whacked" by rebase and
>             AFAICT is not used by Python anyway
>           - cygtclpip80.dll: because it appears not to be relocatable
>
> Additionally, following the suggestions from the MSDN, I rebased from
> 0x68000000 down.  So, all of the above DLLs were rebased into the
range
> of 0x672e0000 - 0x68000000.
>
> After rebasing, the minimal test case that previously exhibited the
> problem:
>
>     http://cygwin.com/ml/cygwin/2001-12/msg00419.html
>
> now works fine.
>
> Unfortunately, when I run the complete Python regression test, I still
> get the same three test failures as reported by Michael without
rebasing:
>
>     test_popen2
>     test_pty
>     test_socket
>
> When I run these tests individually (i.e., not part of the complete
test
> suite), then they pass.  Hence, the rebasing appears not to completely
> solve this problem.
>
> See the attached snippet of output from a regression test run (and
> search for 0x1A).  It shows that although there should not be DLL base
> address conflicts, some DLLs are being rebased in the parent anyway.
> A few examples are:
>
>     _socket.dll: rebased to 0x67f50000 loaded at 0x1A260000
>     cygz.dll:    rebased to 0x678b0000 loaded at 0x1A310000
>
> Would other Python users (with access to MS's rebase tool) be willing
> to try to reproduce my findings to eliminate the possibility of
cockpit
> error on my part?
>
> Does anyone understand why the DLLs are being rebased even though
there
> theoretically is no chance of a base address conflict anymore?
>
> Thanks,
> Jason
>

------------------------------------------------------------------------
--------

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

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