This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)


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

Rob
===
----- Original Message -----
From: "Jason Tishler" <jason@tishler.net>
To: "Cygwin" <cygwin@sources.redhat.com>
Cc: "Michael Hudson" <mwh@python.net>;
<david_abrahams@users.sourceforge.net>
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]