This is the mail archive of the 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.

----- Original Message -----
From: "Jason Tishler" <>
To: "Cygwin" <>
Cc: "Michael Hudson" <>;
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
> > 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
> of 0x672e0000 - 0x68000000.
> After rebasing, the minimal test case that previously exhibited the
> problem:
> 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
>     test_popen2
>     test_pty
>     test_socket
> When I run these tests individually (i.e., not part of the complete
> 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
> error on my part?
> Does anyone understand why the DLLs are being rebased even though
> theoretically is no chance of a base address conflict anymore?
> Thanks,
> Jason


> --
> Unsubscribe info:
> Bug reporting:
> Documentation:
> FAQ:         

Unsubscribe info:
Bug reporting:

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