From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 6F0D23858001 for ; Sun, 28 Feb 2021 03:51:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F0D23858001 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 11S3p8MF085486 for ; Sat, 27 Feb 2021 19:51:08 -0800 (PST) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.20]" via SMTP by m0.truegem.net, id smtpdIdGspd; Sat Feb 27 19:51:01 2021 Subject: Re: binutils 2.36.1 To: Cygwin-Apps References: <87lfb9i7ca.fsf@Rainer.invalid> From: Mark Geisert Message-ID: Date: Sat, 27 Feb 2021 19:51:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <87lfb9i7ca.fsf@Rainer.invalid> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 03:51:14 -0000 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