Mail Archives: cygwin/2001/12/10/07:47:52
Possibly because the cygwin heap is getting allocated across where those
.dll's would go.
Rob
===
----- Original Message -----
From: "Jason Tishler" <jason AT tishler DOT net>
To: "Cygwin" <cygwin AT sources DOT redhat DOT com>
Cc: "Michael Hudson" <mwh AT python DOT net>;
<david_abrahams AT users DOT sourceforge DOT 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/
- Raw text -