X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:from:to:references:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=KWe7aDAU7BPEOXXn
	vvK2OIOF9CGfHCXzqqbu4uMZ4Fg8B6F3YK2xh7CfQqMSihepRgJJMYLMtklcLuHh
	69QvylPkLFKZ6MzJN8KrhbZzZYNfH2oshI0sUDFTsCo68/bOh+BoHlu0fe5vKMbm
	Wb7d7EvBFxpmBGFugTV5cu26Vf0=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:from:to:references:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=LzKFP5pHclL4TBerNyCHDL
	DSGNQ=; b=hJhKKYg6ZUNrSpVXid5JUkXmUHW8n9fUcoCKADHperGvDVXR2LRv2r
	T9lqEM/ue+1BN2X7co3HiX7mgZ3d3qGX2KBfpwlludu9nct9kKzZUQN0Lut/tgGM
	HOPLtiqgrUm1j2HoVaWHZY2w9imCvUdka0Yo/8J7vOMakLRjXKiRE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=1.4 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,TBC autolearn=no version=3.3.1 spammy=orphan, forever, cygwin3071, downgrading
X-HELO:	mail-pf1-f181.google.com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=AhaQajIbdw1QCagIWt/EcrwxoUX5+yGZ0wjzBIOhZZ8=; b=uZoncwhAMwV1L3c+Xfyc/+dbabkR24Ipw9FoeHPhHAz2SvRpkcrB/eh1lloaqERwrB y5/W7tMkIVFHHSi6Px3ayQQGbuZekzmsYycTUDtRMAVB+SvpuSTjggJyUl6IOsSNZlH0 sjd4fNhUea0HrXsjKe532fnjxw0V2cemZNQlQFG54sJ/R2ez9umcMDMKvEp1p22aHMw6 +vEftr+IvPdqpe6RWJwrH3vUA2o9xoMX/ehmWJL8J5+oB91Tjes6tukfrZO6vzi6tHlB FdoKozIMsRGwuRQgF/D+tS7qgF/rGWCsOmBavt+j0qLj77UtGJgPfLt6ya6tEAsdDgdL 58Zw==
Subject:	Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
From:	David Finnie <david DOT finnie68 AT gmail DOT com>
To:	cygwin AT cygwin DOT com
References:	<6d43c714-c4ba-4f0c-9913-cb8453129c85 AT gmail DOT com> <d24aa066-ab3d-9ff0-215a-0a1ed1ec2e5d AT cornell DOT edu> <93562f34-3a14-0c10-cb57-1ae861307d82 AT gmail DOT com>
Message-ID:	<f4a808cf-d129-f6ce-0da8-674cf88a71ad@gmail.com>
Date:	Thu, 2 Jan 2020 10:43:09 +1100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version:	1.0
In-Reply-To:	<93562f34-3a14-0c10-cb57-1ae861307d82@gmail.com>
X-IsSubscribed:	yes

Hi all,

I did as Ken suggested and reverted to 3.0.7-1. (Thanks, Ken !)

That has fixed the issue for me, and the make it now running again at 
full speed. I forgot to mention that it did seem somewhat slower with 
the new version of cygwin.

That strongly implies that there is an issue with changes made since 
then. I noticed that in fork.cc, at line 540, this new code exists:

   /* Do not attach to the child before it has successfully initialized.
      Otherwise we may wait forever, or deliver an orphan SIGCHILD. */
   if (!child.reattach ())
     {
       this_errno = EAGAIN;
#ifdef DEBUGGING0
       error ("child reattach failed");
#endif
       goto cleanup;
     }

Since I am getting "Resource temporarily unavailable", which equates to 
EAGAIN, and this code is new, this looks like the most likely candidate 
to investigate first (but rest assured that I'm not saying that this 
code is definitely the culprit !).

The reattach and parent/child logic looks reasonably complex and I've 
only just downloaded the code, so I'm not sure that I want to try fixing 
anything for fear of breaking much more.

Could someone please scan an eye over this code ? I noticed that there 
were 2 commits related to this - moving the reattach() until later 
processing. Is it possible that there is still an opportunity that the 
reattach() fails even when things are working properly ?

Thanks.

Dave

On 2/01/2020 09:32, David Finnie wrote:
> Hi Ken,
>
> Thanks for having a look at my issue.
>
> On 1/01/2020 06:20, Ken Brown wrote:
>> On 12/30/2019 6:10 PM, David Finnie wrote:
>>> I recently upgraded my cygwin64 installation to get latest packages.
>>>
>>> After the install, if I run a fairly lengthy GNU make with multiple 
>>> concurrent
>>> jobs (-j option) specified, some of the sub-makes fail with "Resource
>>> temporarily unavailable" errors. In all cases, this has been when 
>>> make is
>>> starting a shell (i.e. $(shell ...) ) to help with setting up some 
>>> of the
>>> variables required in the make processing. The failure, however, 
>>> occurs in
>>> different places in the make files used (the make spawns several 
>>> sub-makes).
>> Does this happen with every parallel make, or is it one specific 
>> program that
>> you're building?  If the latter, can you give a detailed recipe so 
>> that others
>> can try to reproduce the problem?
>
> It's happening consistently across a bunch of libraries and 
> executables that I build (with a series of invocations of make). While 
> each of those builds has their own Makefile, each of them includes a 
> common set of makefiles that does the vast majority of the work, so I 
> guess you could say that it really is just isolated (as far as I can 
> tell), to one build environment. The build is not of open source 
> software - it is for software created by the company I work for, so 
> unfortunately I can't share all of the source code etc., but I can 
> certainly give details of what we're doing.
>
> The make builds a cross-platform set of products, and so invokes both 
> Windows native compilers, and also cross compilers for the other 
> platforms (Linux, and HPE NonStop). So there are many tools being 
> invoked simultaneously.
>
> Keep in mind, though, that this has been working perfectly for me for 
> over a decade. I will say that I did run into the need to run rebase 
> after upgrading cygwin many years ago, but that fixed the issue for me 
> immediately. Not so this time, and there has been nothing else changed 
> in my environment. I actually ran the build successfully just minutes 
> before upgrading the cygwin packages, and then it failed immediately 
> after that.
>
> I have not tried building for any other product. I might try that.
>
>> Have you tried reverting to cygwin-3.0.7-1? 
>
>
> No, I haven't - I'll try that now. Thanks.
>
>
>>
>> The only thing that jumps out at me from your cygcheck output is that 
>> your PATH
>> is very long.  I don't know if that's relevant, but you might try 
>> cutting it
>> down before running make.
>
>
> I did try changing PATH to a much smaller value 
> (/bin:/usr/bin:/usr/local/bin) but I still got exactly the same 
> behaviour :-( A good thing to try, though.
>
> I'll see how I go after downgrading cygwin.
>
> Thanks again.
>
> Dave
>

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

- Raw text -