Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Jason Tishler wrote:


>>
>>building 'gdbm' extension
>>gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I. -I/cygdrive/e/Python-2.2b2/./Include -I/usr/local/include -IInclude/ -c /cygdrive/e/Python-2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3.5-i686-2.2/gdbmmodule.o
>>e:\buildpy\python.exe: *** unable to remap 
>>C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000
>>      0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1
>>  25901 [main] python 1292 sync_with_child: *** child state child loading dlls
>>error: Resource temporarily unavailable
>>make: *** [sharedmods] Error 1
>>
> 
> The above occurs during Cygwin's fork() when the Cygwin DLL cannot
> load a DLL to the same address in the child that it had in the parent.
> I have seen this during Python 2.1.1 regression tests with threads
> enabled.


Part of the problem may be that cyggdbm.dll was built with 
--auto-image-base.  It was later demonstrated that this can cause 
problems with fork; you're better off just letting ld assign the default 
dllbase, which means that EVERY process will remap the dll at runtime. 
Thus, no hardcoded conflicts.  Downside: *very* slightly delay in 
loading DLLs -- probably unnoticeable.

(Did I get that right, robert?)

Anyway, I plan to redo cyggdbm "eventually" without the 
--auto-image-base.  Doing so *may* fix this problem, but I'm not sure...

--Chuck






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