This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: random "fork: Resource temporarily unavailable"

Mark Bartel wrote:
Larry Hall wrote:
Linda Walsh wrote:
I've not seen this message except when I've had to rapidly
press ^C to break out of a loop shell script.

Today, I've seen it twice when there was virtually no cpu load
on the system, about 50% virtual memory committed, and 40 processes.

Once, was with an "ls" command, the other happened as my shell was
starting up by some command invoked in the .rc script.

I get suspicious whenever I see behavior on my computers when
anomalies crop up.

I don't think any of my cygwin libraries have been updated recently.

What would cause something like this?  Memory fragmentation?
Insufficient real memory to "immediately" fork?  I.e. I wonder
if, when NT goes to "fork", if it doesn't have enough free
memory, it tells the caller it failed (try again later) and
then starts a memory cleanup cycle to free up memory: i.e. rather
than the forking process sleeping while memory is made available
NT returns it immediately with a failure.

Any idea on causes?  Is it as rare as it has been for me?
A possible solution would be retry the fork a second time, or
sleep for a millisecond and then try fork again. I'm not sure,
but I think many *ixy (*='un'|'pos'|'lin'|'ir'...etc) type programs
may not retry the fork  but immediately die, as on *ixy systems,
a fork failure is less common, and usually only happens when
the system really is out of resources.  If that's the case,
it _might_ be an aid to smooth *ixy compatibility for the
library handling fork, retry the fork (possibly with millisecond
sleep) once before returning failure to the application.

Not a high priority issue, but just wondering....

If it is NT returning failure rather than
forking, I wonder if, in order to provide a better "run-time"

If you can reproduce this problem, I would suggest trying it again
a recent snapshot.

This sounds like the same issue I was encountering. I can reproduce it on demand with:

mbartel@mbartel-t60p ~
$ find * -type f -exec grep foo {} /dev/null \;
      6 [main] find 435884 fhandler_dev_zero::fixup_mmap_after_fork:
requested 0x480000 != 0x0 mem alloc base 0x480000, state 0x2000, size
1040384, Win32 error 487
    272 [main] find 435884 C:\cygwin\bin\find.exe: *** fatal error -
C:\cygwin\bin\find.exe: *** recreate_mmaps_after_fork_failed
     13 [main] find 434720 child_info::sync: wait failed, pid 435884,
Win32 error 0
    344 [main] find 434720 fork: child -1 - died waiting for longjmp
before initialization, retry 10, exit code 0x1000000, errno 11
find: cannot fork: Resource temporarily unavailable

mbartel@mbartel-t60p ~

Unfortunately, it is more than just annoying in my case, as it happens
all the time.  I had to buy MKS Toolkit to get on with my job.

So are you saying you still see the problem after using a recent snapshot

-- Larry Hall RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]