This is the mail archive of the
mailing list for the Cygwin project.
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
- Date: Thu, 2 Jan 2020 10:43:09 +1100
- Subject: Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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;
error ("child reattach failed");
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 ?
On 2/01/2020 09:32, David Finnie wrote:
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:
Does this happen with every parallel make, or is it one specific
you're building? If the latter, can you give a detailed recipe so
I recently upgraded my cygwin64 installation to get latest packages.
After the install, if I run a fairly lengthy GNU make with multiple
jobs (-j option) specified, some of the sub-makes fail with "Resource
temporarily unavailable" errors. In all cases, this has been when
starting a shell (i.e. $(shell ...) ) to help with setting up some
variables required in the make processing. The failure, however,
different places in the make files used (the make spawns several
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
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
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
is very long. I don't know if that's relevant, but you might try
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple