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: [RFC] an alternative to rebasing

On Mon, Aug 05, 2002 at 12:41:44 -0400, Jason Tishler wrote:

> I'm sorry to report that your patch does not fix the following rebase
> problem:
> Specifically, I'm getting the following:
>     $ make
>     ...
>     building 'gdbm' extension
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I.
> -I/tmp/python-2.2.1-1/./Include -I/usr/local/include -IInclude/ -c
> /tmp/python-2.2.1-1/Modules/gdbmmodule.c -o
> build/temp.cygwin-1.3.13-i686-2.2/gdbmmodule.o
> C:\cygwin\tmp\python-2.2.1-1\build\python.exe: *** unable to remap
> C:\cygwin\bin\cygcrypto.dll to same address as parent -- 0x420000
>       8 [main] python 1548 sync_with_child: child 2772(0x100) died
>       before initialization with status code 0x1
>    9652 [main] python 1548 sync_with_child: *** child state child
>    loading dlls
> error: Resource temporarily unavailable
> make: *** [sharedmods] Error 1

I've looked into this, and the problem now is with the imagebases of the
python dlls. The makefile is linking them with
"--enable-auto-image-base" and you will find that at least two of these
values clash:
_codecs.dll: 0x69400000
libpython2.2.dll: 0x69340000
Now that *should not* pose a problem if we had a rock-solid fork()
implementation, but my patch is just a work-around, not a proper fix.
However, --enable-auto-image-base is deprecated in cygwin anyway,
because it may mean that a dll is given an image base that clashes with
cygwin1.dll, which should never be relocated (IIRC according to the
mailing list archives of last year).
So, you should remove the --enable-auto-image-base flag, then your dlls
will all get the default image base of 0x10000000, and cygwin with my
patch is able to load and fork without problem!

BTW I fully agree with Rob Collins that an effective rebase tool will
give measurable performance improvements to cygwin apps and so this
patch is not strictly an alternative to rebasing, but I think it is
still a sensible change to the fork() implementation. This is because
rebase should be an option to improve performance, not a necessity to
permit function.

Are there any cygwin regression tests that I can use to look for any
undesirable side-effects of my patch?


Unsubscribe info:
Bug reporting:

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