Mail Archives: cygwin/2006/06/20/14:26:04
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
<http://cygwin.com/snapshots/>?
--
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/
- Raw text -