This is the mail archive of the
mailing list for the Cygwin project.
Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Jason Tishler" <jason at tishler dot net>,"Cygwin" <cygwin at sources dot redhat dot com>
- Cc: "Michael Hudson" <mwh at python dot net>,<david_abrahams at users dot sourceforge dot net>
- Date: Mon, 10 Dec 2001 23:42:01 +1100
- Subject: Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
- References: <20011210074629.B2148@dothill.com>
Possibly because the cygwin heap is getting allocated across where those
.dll's would go.
----- Original Message -----
From: "Jason Tishler" <firstname.lastname@example.org>
To: "Cygwin" <email@example.com>
Cc: "Michael Hudson" <firstname.lastname@example.org>;
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
> - 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
> 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
> 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?
> 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