bzr problem

bzr problem

[Katsumi Yamaoka]

Hi,

Recently /usr/bin/bzr doesn't work well.  For the Emacs trunk,
those two commands achieve the purpose even if issuing a warning:

$ bzr update
$ bzr commit -m "Bla bla"

Usually a warning is like:
0 [main] python2.7 1264 child_info_fork::abort: address space needed by 'math.dll' (0x800000) is already occupied

But it is sometimes:
1 [main] python2.7 5784 child_info_fork::abort: unable to remap _ARC4.dll to same address as parent (0xBE0000) - try running rebaseall

Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.
How can I fix this problem?

And what is worse is that bzr fails to commit changes when I use
`bzr commit' (w/o arg) to try to write a commit message by using
an EDITOR.  At that time, bzr issues similar `child_info_fork'
messages, fails to start an editor, and quits.  (I cannot show
an actual session, since I now have no change to commit to the
Emacs trunk, sorry).

Thanks in advance.
Regards,


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

Re: bzr problem

[Ken Brown]

On 7/11/2013 12:32 AM, Katsumi Yamaoka wrote:
> Hi,
>
> Recently /usr/bin/bzr doesn't work well.  For the Emacs trunk,
> those two commands achieve the purpose even if issuing a warning:
>
> $ bzr update
> $ bzr commit -m "Bla bla"
>
> Usually a warning is like:
> 0 [main] python2.7 1264 child_info_fork::abort: address space needed by 'math.dll' (0x800000) is already occupied
>
> But it is sometimes:
> 1 [main] python2.7 5784 child_info_fork::abort: unable to remap _ARC4.dll to same address as parent (0xBE0000) - try running rebaseall
>
> Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.

Did you run rebaseall *after* reinstalling bzr and python?  Reinstalling 
undoes the rebasing.  If that still doesn't help, try looking at the 
output of 'rebase -is' to see if it shows DLL collisions (marked with an 
asterisk).  You might also try moving /etc/rebase.db.i386 out of the way 
and the running rebaseall again, so that it can start with a clean slate.

Ken


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

Re: bzr problem

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

Ken Brown wrote:
> On 7/11/2013 12:32 AM, Katsumi Yamaoka wrote:
>> Hi,
>>
>> Recently /usr/bin/bzr doesn't work well.  For the Emacs trunk,
>> those two commands achieve the purpose even if issuing a warning:
>>
>> $ bzr update
>> $ bzr commit -m "Bla bla"
>>
>> Usually a warning is like:
>> 0 [main] python2.7 1264 child_info_fork::abort: address space needed
>> by 'math.dll' (0x800000) is already occupied
>>
>> But it is sometimes:
>> 1 [main] python2.7 5784 child_info_fork::abort: unable to remap
>> _ARC4.dll to same address as parent (0xBE0000) - try running
>> rebaseall
>>
>> Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.

> Did you run rebaseall *after* reinstalling bzr and python?

Yes, I did.

> Reinstalling undoes the rebasing.  If that still doesn't help, try
> looking at the output of 'rebase -is' to see if it shows DLL
> collisions (marked with an asterisk).

No asterisk appears.  This is a superfluity, though:

$ rebase -is| awk '{print $3}'| wc -l
2695
% rebase -is| awk '{print $3}'| sort -u| wc -l
2695

I also ran a small program[1] in the output to verify there is
no overlap in the addresses.

> You might also try moving /etc/rebase.db.i386 out of the way and the
> running rebaseall again, so that it can start with a clean slate.

I tried it but nothing changed.  Thanks anyway.

[1]

[-- Attachment #2: Type: application/emacs-lisp, Size: 976 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: bzr problem

[Katsumi Yamaoka]

Please ignore my last reply (there's something wrong in MIME encoding).

Ken Brown wrote:
> On 7/11/2013 12:32 AM, Katsumi Yamaoka wrote:
>> Hi,
>>
>> Recently /usr/bin/bzr doesn't work well.  For the Emacs trunk,
>> those two commands achieve the purpose even if issuing a warning:
>>
>> $ bzr update
>> $ bzr commit -m "Bla bla"
>>
>> Usually a warning is like:
>> 0 [main] python2.7 1264 child_info_fork::abort: address space needed
>> by 'math.dll' (0x800000) is already occupied
>>
>> But it is sometimes:
>> 1 [main] python2.7 5784 child_info_fork::abort: unable to remap
>> _ARC4.dll to same address as parent (0xBE0000) - try running
>> rebaseall
>>
>> Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.

> Did you run rebaseall *after* reinstalling bzr and python?

Yes, I did.

> Reinstalling undoes the rebasing.  If that still doesn't help, try
> looking at the output of 'rebase -is' to see if it shows DLL
> collisions (marked with an asterisk).

No asterisk appears.  This is a superfluity, though:

$ rebase -is| awk '{print $3}'| wc -l
2695
% rebase -is| awk '{print $3}'| sort -u| wc -l
2695

I also ran a small program[1] in the output to verify there is
no overlap in the addresses.

> You might also try moving /etc/rebase.db.i386 out of the way and the
> running rebaseall again, so that it can start with a clean slate.

I tried it but nothing changed.  Thanks anyway.

[1]
\f
(let (base size next)
  (goto-char (point-min))
  (while (not (eobp))
    (when (looking-at
	   ".* base \\(0x\\([0-9a-f]+\\)\\) size \\(0x\\([0-9a-f]+\\)\\)")
      (setq base (string-to-number (match-string 2) 16)
	    size (string-to-number (match-string 4) 16)
	    next (+ base size))
      (end-of-line)
      (insert "next " (number-to-string next))
      (delete-region (goto-char (match-beginning 3)) (match-end 3))
      (insert (number-to-string size))
      (delete-region (goto-char (match-beginning 1)) (match-end 1))
      (insert (number-to-string base)))
    (forward-line 1))
  (sort-numeric-fields 3 (point-min) (point-max))
  (goto-char (point-min))
  (while (re-search-forward "next \\([.0-9]+\\)" nil t)
    (setq next (string-to-number (match-string 1)))
    (forward-line 1)
    (when (looking-at ".* base \\([.0-9]+\\)")
      (setq base (string-to-number (match-string 1)))
      (when (> next base)
	(error "Overlap!")))))


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

Re: bzr problem

[Achim Gratz]

Katsumi Yamaoka writes:
> 0 [main] python2.7 1264 child_info_fork::abort: address space needed by 'math.dll' (0x800000) is already occupied
>
> But it is sometimes:
> 1 [main] python2.7 5784 child_info_fork::abort: unable to remap _ARC4.dll to same address as parent (0xBE0000) - try running rebaseall
>
> Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.
> How can I fix this problem?

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?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds


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

Re: bzr problem

[Katsumi Yamaoka]

Achim Gratz wrote:
> Katsumi Yamaoka writes:
>> 0 [main] python2.7 1264 child_info_fork::abort: address space needed
>> by 'math.dll' (0x800000) is already occupied
>>
>> But it is sometimes:
>> 1 [main] python2.7 5784 child_info_fork::abort: unable to remap
>> _ARC4.dll to same address as parent (0xBE0000) - try running
>> rebaseall
>>
>> Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.
>> How can I fix this problem?

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


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

Re: bzr problem

[Achim Gratz]

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables


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

Re: bzr problem

[Katsumi Yamaoka]

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

Re: bzr problem

[Achim Gratz]

Katsumi Yamaoka writes:
> 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

What apparently happens is that the DLL gets originally loaded onto a
low address, presumably due to something intercepting the loader, then
when the process forks that address is already in use so the DLL can't
be mapped to that address in the process image.  This has all the
fingerprints of a "real-time" / behavioural virus scanner, so you might
want to investigate whether you can exclude the Cygwin install folder
from this.  If that's not possible to set up, you can sometimes move the
Cygwin installation into a directory tree that already is excluded
(often %PROGRAMFILES% is treated differently than other tress, etc.).

> 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"?

Not at all: the DLL simply doesn't get loaded where it has been rebased
to.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds


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

Re: bzr problem

[Katsumi Yamaoka]

Solved.  What I've done was the clean install[1].  But I don't
know what did the trick nor the cause of the problem[2] after
all.  Performing rebaseall doesn't seem to do any harm in this
installation.

Regards,

[1] Rename c:\cygwin\ to c:\cygwin_old\
    Install Cygwin in c:\cygwin\ using setup.exe
    Copy /usr/local and /home stuff from cygwin_old to cygwin
[2] http://thread.gmane.org/gmane.os.cygwin/140753


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