Re: binutils 2.36.1

[Mark Geisert <mark@maxrnd.com>]

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