binutils 2.36.1

binutils 2.36.1

[Achim Gratz]

Before releasing binutils 2.35.2, I had already built 2.36 (which was
released two days earlier), but it became almost immediately clear that
there were problems.  Now that 2.36.1 came out I tried again (not that
the changes would indicate anything addressing those problems) and of
course the problems are still there.  With the new binutils installed, I
get lots of fork problems on x86, but not exactly reproducible.  Like
these:

--8<---------------cut here---------------start------------->8---
checking for working fork...       1 [main] conftest 7615 D:\Freeware\CygProShare\cygpkgs\mosh\mosh.x86\build\conftest.exe: *** fatal error in forked process - fork: can't reserve 
memory for parent stack 0x1400000 - 0x1600000, (child has 0x840000 - 0xA40000), Win32 error 487
  74330 [main] conftest 7615 cygwin_exception::open_stackdumpfile: Dumping stack trace to conftest.exe.stackdump
      1 [main] conftest 7614 dofork: child -1 - forked process 1224 died unexpectedly, retry 0, exit code 0x100, errno 11
no
--8<---------------cut here---------------end--------------->8---

I have yet to find any mention of a change to binutils that would
explain what is going on, so if anybody could have a look and generate
an hypothesis that would be most helpful.  You can use the cygport file
and just change the version number (plus the name of the patch file to
match the version).


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

Re: binutils 2.36.1

[Mark Geisert]

Achim Gratz wrote:
> Before releasing binutils 2.35.2, I had already built 2.36 (which was
> released two days earlier), but it became almost immediately clear that
> there were problems.  Now that 2.36.1 came out I tried again (not that
> the changes would indicate anything addressing those problems) and of
> course the problems are still there.  With the new binutils installed, I
> get lots of fork problems on x86, but not exactly reproducible.  Like
> these:
> 
> --8<---------------cut here---------------start------------->8---
> checking for working fork...       1 [main] conftest 7615 D:\Freeware\CygProShare\cygpkgs\mosh\mosh.x86\build\conftest.exe: *** fatal error in forked process - fork: can't reserve
> memory for parent stack 0x1400000 - 0x1600000, (child has 0x840000 - 0xA40000), Win32 error 487
>    74330 [main] conftest 7615 cygwin_exception::open_stackdumpfile: Dumping stack trace to conftest.exe.stackdump
>        1 [main] conftest 7614 dofork: child -1 - forked process 1224 died unexpectedly, retry 0, exit code 0x100, errno 11
> no
> --8<---------------cut here---------------end--------------->8---
> 
> I have yet to find any mention of a change to binutils that would
> explain what is going on, so if anybody could have a look and generate
> an hypothesis that would be most helpful.  You can use the cygport file
> and just change the version number (plus the name of the patch file to
> match the version).

I have now built and installed x86 binutils 2.36.1 locally.  I've been able to 
build the Cygwin DLL and mosh without issues.  I suspect you might be right on the 
edge of running out of address space given your symptoms are erratically recurring 
and it's on x86.

As a basis for comparison I've got 293 DLLs according to 'rebase -i *.dll|wc -l' 
in the /usr/bin directory.  'rebase -i *.dll | head' shows this:

/usr/bin/tk86.dll                             base 0x59b80000 size 0x0015e000
/usr/bin/libtk8.6.dll                         base 0x59ce0000 size 0x00149000
/usr/bin/libtcl8.6.dll                        base 0x59e30000 size 0x001a8000
/usr/bin/libpython3.8.dll                     base 0x59fe0000 size 0x002d6000
/usr/bin/libpython3.6m.dll                    base 0x5a2c0000 size 0x00279000
/usr/bin/libpython2.7.dll                     base 0x5a540000 size 0x001cd000
/usr/bin/libexpect5.45.dll                    base 0x5a710000 size 0x00031000
/usr/bin/libbtparse.dll                       base 0x5a750000 size 0x00020000
/usr/bin/cygzzipwrap-0-13.dll                 base 0x5a770000 size 0x0000b000
/usr/bin/cygzzipmmapped-0-13.dll              base 0x5a780000 size 0x0000c000

The output is sorted by base address.  See where your lowest DLL is based; that 
should tell you if you'll need to prune some lesser-used packages to free up some 
DLL address space.

..mark

Re: binutils 2.36.1

[ASSI]

Mark Geisert writes:
> I have now built and installed x86 binutils 2.36.1 locally.  I've been
> able to build the Cygwin DLL and mosh without issues.  I suspect you
> might be right on the edge of running out of address space given your
> symptoms are erratically recurring and it's on x86.

I don't think so or I wouldn't have been able to build Perl, which
needed quite a lot of extra space for the ephemeral rebases on x86.
Also not that while it produces a for error, it's actually the stack
that moves, something I haven't previously seen to happen when I run out
of address space.

> As a basis for comparison I've got 293 DLLs according to 'rebase -i
> *.dll|wc -l' in the /usr/bin directory.  'rebase -i *.dll | head'
> shows this:

rebase -si | head

is way easier and shows you the real thing.

> The output is sorted by base address.  See where your lowest DLL is
> based; that should tell you if you'll need to prune some lesser-used
> packages to free up some DLL address space.

I'm down to 0x329d and there really isn't all that much I can remove if
I need to keep building all my packages.  There are quite some libraries
that I have in multiple versions due to the dependent packages not
having been rebuilt after the library update, but that's nothing I can
help.

[…]
OK, so some helpful idiot has decided that the ASLR and NXcompat flags
should be on by default.  How this is not something that belongs into
the ChangeLog is anybodies guess.
}:-(

So once I find out how to best get rid of that it should start working
again I guess.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves