X-Spam-Check-By: sourceware.org Message-ID: <44983DAC.2030008@cygwin.com> Date: Tue, 20 Jun 2006 14:25:48 -0400 From: "Larry Hall (Cygwin)" Reply-To: cygwin AT cygwin DOT com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060112 Fedora/1.5-1.fc4.remi Thunderbird/1.5 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: random "fork: Resource temporarily unavailable" References: <251D2B65F6DECE47A69C7C3AB504D72FB283A8 AT namail2 DOT corp DOT adobe DOT com> In-Reply-To: <251D2B65F6DECE47A69C7C3AB504D72FB283A8@namail2.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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.... >>> >>> Linda >>> 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 > with >> a recent snapshot. > > This sounds like the same issue I was encountering. I can reproduce it > on demand with: > > mbartel AT 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 AT 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 http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/