Re: bzr problem

[Katsumi Yamaoka <yamaoka@jpl.org>]

Achim Gratz wrote:
> Katsumi Yamaoka writes:
>>> I'd venture to guess that the DLL(s) in question belong to a Python
>>> package.  If so, does the rebaseall script you are using look at those
>>> libraries at all?
>>
>> As far as I can observe, those DLLs are listed in TEMP/rebase.lst
>> (that rebaseall temporarily generates), and `rebaseall -v' shows
>> that they are processed by `rebase'.  Thanks.

> You could dump the contents of the rebase database then and check what
> the base address for this library is supposed to be.  Chances are that
> it is very much higher than what your example of a fork fail shows.  In
> my experience, such low base addresses indicate BLODA; however if a
> library is indeed rebased into this region it has almost zero chances of
> correctly forking in that address range.

Sorry, I don't know what the proper base address is, how it is
decided, nor what a value causes.  If possible, could you spend
a little time to look into the rebaseall log I made?  Here it is:

http://www.jpl.org/tmp/rebaseall_log.txt

At that time, I ran `rebaseall -v' and verified it ran `rebase'
as follows:

rebase -v -n -s -4\
 -T /cygdrive/c/Users/yamaoka/AppData/Local/Temp/rebase.lst

BTW, when I run `bzr update' for the Emacs trunk, it shows a warning
that varies like:

0 [main] python2.7 1300 child_info_fork::abort: unable to remap\
_ARC4.dll to same address as parent (0xBE0000) - try running rebaseall
0 [main] python2.7 4180 child_info_fork::abort: address space needed by\
 '_socket.dll' (0x860000) is already occupied
0 [main] python2.7 8072 child_info_fork::abort: address space needed by\
 'operator.dll' (0x3D0000) is already occupied

rebaseall_log.txt shows that those DLLs were rebased into:

/usr/lib/python2.7/site-packages/Crypto/Cipher/_ARC4.dll:\
 new base = 36df0000, new size = 10000
/usr/lib/python2.7/lib-dynload/_socket.dll:\
 new base = 37170000, new size = 20000
/usr/lib/python2.7/lib-dynload/operator.dll:\
 new base = 36f90000, new size = 10000

As for "_ARC4.dll", how does "36df0000" mean "0xBE0000"?

Thanks in advance.
Regards,

P.S. I tried running rebaseall also for some files I installed in
/usr/local, but it didn't help.  What I did then was:

--- rebaseall~	2013-01-16 16:36:08.000000000 +0000
+++ rebaseall	2013-07-16 09:47:40.982715800 +0000
@@ -221,6 +221,8 @@
     ;;
 esac
 
+find /usr/local -regex '.+\.\(dll\|so\|oct\)$' >> "$TmpFile"
+
 # Append user supplied file list, if any
 if [ -n "${FileList}" ]
 then


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple