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 ...)


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

Attachment: rebase.txt
Description: Text document

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