Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Thu, 13 Feb 2020 22:42:31 +0100 Peter Dons Tychsen wrote: > On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote: > > Could you please try latest snapshot? > > https://cygwin.com/snapshots/ > > The commit regarding use of kill() does the trick. > It's a go from here :-). > > Thanks for all the help, Thanks for testing. I had looked into the make problem further, and found this was not caused by the errno overwriting, but by calling sig_dispatch_pending() in fixup_after_exec() via kill(). fixup_after_exec() is called from dll_crt0_0(). It seems that calling sig_dispatch_pending() from dll_crl0_0() causes hangs everywhere (even outside PTY). I am not sure what exactly does sig_dispatch_pending() and why this causes the problem, anyway, using pinfo() rather than kill() solves the issue. Thanks. -- Takashi Yano -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi Takashi, On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote: > Could you please try latest snapshot? > https://cygwin.com/snapshots/ The commit regarding use of kill() does the trick. It's a go from here :-). Thanks for all the help, /pedro -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Wed, 12 Feb 2020 11:54:02 +0100 Peter Dons Tychsen wrote: > Hi Takashi, > > On Wed, 2020-02-12 at 11:24 +0900, Takashi Yano wrote: > > My failure in pty code was that I used kill() in pty system > > calls. kill() can be used check if the process is still alive > > by passing signal number of 0 to the second argument. It returns > > -1 if the process already exited. However, in this case errno > > is set to ESRCH. As a result, the errno value which pty system > > call set is accidentally overwritten by kill(). > > OK, thanks for clearing all that up. Just wanted to make sure kill() > was not buggy :-). > > I will test the committed patch and the upcoming release vigerously to > see if there are still bugs to be found in this area. Not sure why i > get fork() errors and you do not (my tests with the example i made > always causes fork() errors in 3.1.2). > > Thanks for all the help and your snappy replies, Could you please try latest snapshot? https://cygwin.com/snapshots/ -- Takashi Yano -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Tue, 11 Feb 2020 09:21:32 -0500 Ken Brown wrote: > On 2/11/2020 8:16 AM, Takashi Yano wrote: > > On Tue, 11 Feb 2020 11:38:35 +0100 > > Peter Dons Tychsen wrote: > >> On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote: > >>> Is this the same as your problem? > >> > >> Yeah, it could be. Could this result in fork error messages as we are > >> seeing all over the place? > > > > No. Fork error is not seen in my environment. This could be another > > problem. However, the code using kill() below is called also by fork(). > > So, it may be related. > > FWIW, I'm not seeing the fork error in my environment either. I see the hang > prior to your kill() patch, and then no problem (except for the ld error). I tested under Win10 1809 and found fork error occurs in that environment. Also confirmed the kill() patch fixes the issue. -- Takashi Yano -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Feb 12 11:24, Takashi Yano wrote: > On Tue, 11 Feb 2020 22:31:12 +0100 > Peter Dons Tychsen wrote: > > On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote: > > > however, I found the real cause is that errno is accidentally set > > > by kill() in pty system calls. That is, the problem is not in the > > > kill() itself but in usage of it. Cygwin older than 3.1.0 does not > > > have these code in pty. > > > > OK, is there a fix for that or is that the fix you already pushed? And > > what is wrong with the usage of kill(). How can kill() be used > > incorrectly? > > POSIX system calls set global variable errno to appropriate > value when the system calls fail. > http://man7.org/linux/man-pages/man3/errno.3.html > > My failure in pty code was that I used kill() in pty system > calls. kill() can be used check if the process is still alive > by passing signal number of 0 to the second argument. It returns > -1 if the process already exited. However, in this case errno > is set to ESRCH. As a result, the errno value which pty system > call set is accidentally overwritten by kill(). > > The patch was already accepted and pushed to git repository. > I hope cygwin 3.1.3 which applied this patch will be released > shortly. For a first test, please try the latest developer snapshot on https://cygwin.com/snapshots/ Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Tue, 11 Feb 2020 22:31:12 +0100 Peter Dons Tychsen wrote: > On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote: > > however, I found the real cause is that errno is accidentally set > > by kill() in pty system calls. That is, the problem is not in the > > kill() itself but in usage of it. Cygwin older than 3.1.0 does not > > have these code in pty. > > OK, is there a fix for that or is that the fix you already pushed? And > what is wrong with the usage of kill(). How can kill() be used > incorrectly? POSIX system calls set global variable errno to appropriate value when the system calls fail. http://man7.org/linux/man-pages/man3/errno.3.html My failure in pty code was that I used kill() in pty system calls. kill() can be used check if the process is still alive by passing signal number of 0 to the second argument. It returns -1 if the process already exited. However, in this case errno is set to ESRCH. As a result, the errno value which pty system call set is accidentally overwritten by kill(). The patch was already accepted and pushed to git repository. I hope cygwin 3.1.3 which applied this patch will be released shortly. -- Takashi Yano -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi Takashi, Thanks for your effort. On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote: > however, I found the real cause is that errno is accidentally set > by kill() in pty system calls. That is, the problem is not in the > kill() itself but in usage of it. Cygwin older than 3.1.0 does not > have these code in pty. OK, is there a fix for that or is that the fix you already pushed? And what is wrong with the usage of kill(). How can kill() be used incorrectly? Is there are more things here it would be great to get them in for the 3.1.3 release. Thanks, /pedro -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On 2/11/2020 8:16 AM, Takashi Yano wrote: On Tue, 11 Feb 2020 11:38:35 +0100 Peter Dons Tychsen wrote: On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote: Is this the same as your problem? Yeah, it could be. Could this result in fork error messages as we are seeing all over the place? No. Fork error is not seen in my environment. This could be another problem. However, the code using kill() below is called also by fork(). So, it may be related. FWIW, I'm not seeing the fork error in my environment either. I see the hang prior to your kill() patch, and then no problem (except for the ld error). Ken -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Tue, 11 Feb 2020 11:38:35 +0100 Peter Dons Tychsen wrote: > On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote: > > Is this the same as your problem? > > Yeah, it could be. Could this result in fork error messages as we are > seeing all over the place? No. Fork error is not seen in my environment. This could be another problem. However, the code using kill() below is called also by fork(). So, it may be related. I have not investigated your problem on make, so the mechanism to cause the problem is not clear. I do not have confidence that this patch really fixes your problem. > > If so, it goes without stopping 1 minute with patch: > > https://cygwin.com/ml/cygwin-patches/2020-q1/msg00148.html > > Nice trick to use pinfo as a work-around, but i could fear that others > also call kill() at this critical time. Is there an actual fix for > kill() in the cooking? I could fear that tools like "make" actually > call this all over the place, especially if its aborting running > processes. And why did this work before? The commit message says: > This seems to be caused by invalid pointer access which occurs > when the process exits during the kill() code is execuetd. This > patch avoids the issue by not using kill(). however, I found the real cause is that errno is accidentally set by kill() in pty system calls. That is, the problem is not in the kill() itself but in usage of it. Cygwin older than 3.1.0 does not have these code in pty. On Tue, 11 Feb 2020 11:40:45 +0100 Peter Dons Tychsen wrote: > And why does it work when running without minnty? How does that play > into this? The code which has this problem is in the pty code. So, this occurs only in pty such as mintty, xterm, etc. Console (cygwin in command prompt) does not use pty, so problem does not occur in console. -- Takashi Yano -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Tue, 2020-02-11 at 11:38 +0100, Peter Dons Tychsen wrote: > processes. And why did this work before? And why does it work when running without minnty? How does that play into this? Thanks, /pedro -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi Takashi, Thanks for looking at this & your great work on Cygwin! On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote: > Is this the same as your problem? Yeah, it could be. Could this result in fork error messages as we are seeing all over the place? > If so, it goes without stopping 1 minute with patch: > https://cygwin.com/ml/cygwin-patches/2020-q1/msg00148.html Nice trick to use pinfo as a work-around, but i could fear that others also call kill() at this critical time. Is there an actual fix for kill() in the cooking? I could fear that tools like "make" actually call this all over the place, especially if its aborting running processes. And why did this work before? > In any case, the following error occurs. > > /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc- > cygwin/bin/ld:test00.d: file format not recognized; treating as > linker script That looks OK. Ignore the actual result of the makefile, its just garbage :-). Its only to reproduce this error. Thanks again for helping, /pedro -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Mon, 10 Feb 2020 21:58:09 +0100 Peter Dons Tychsen wrote: > 1) Put attached makefile somewhere > 2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe > and unzip it in same place. > 3) Now run "make create" > 4) Now run "make clean && make -j32". Try a couple of times. > > --- > > a) If running via mintty - it hangs fairly quickly, and the task- > manager will show hanging gcc's and sh's. Thanks for the test case. With cygwin 3.1.2, I confirmed make stops for a minute at: . . echo running thread 98 echo running thread 99 running thread 98 cc-c -o hang.o hang.c running thread 99 MinGW/bin/gcc -MP -MM -MT test98.d -M -o test98.d test98.c && MinGW/bin/gcc -c - o test98.o test98.c MinGW/bin/gcc -MP -MM -MT test99.d -M -o test99.d test99.c && MinGW/bin/gcc -c - o test99.o test99.c cc-c -o test.o test.c and displays following after a minute. cc hang.o test00.d test01.d test02.d test03.d test04.d test05.d test06.d test07.d test08.d test09.d test10.d test11.d test12.d test13.d test14.d test15.d test16.d test17.d test18.d test19.d test20.d test21.d test22.d test23.d test24.d test25.d test26.d test27.d test28.d test29.d test30.d test31.d test32.d test33.d test34.d test35.d test36.d test37.d test38.d test39.d test40.d test41.d test42.d test43.d test44.d test45.d test46.d test47.d test48.d test49.d test50.d test51.d test52.d test53.d test54.d test55.d test56.d test57.d test58.d test59.d test60.d test61.d test62.d test63.d test64.d test65.d test66.d test67.d test68.d test69.d test70.d test71.d test72.d test73.d test74.d test75.d test76.d test77.d test78.d test79.d test80.d test81.d test82.d test83.d test84.d test85.d test86.d test87.d test88.d test89.d test90.d test91.d test92.d test93.d test94.d test95.d test96.d test97.d test98.d test99.d -o hang /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld:test00.d: file format not recognized; treating as linker script /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld:test00.d:1: syntax error collect2: error: ld returned 1 exit status make: *** [: hang] Error 1 make: *** Waiting for unfinished jobs rm hang.o test.o hang.c test.c Is this the same as your problem? If so, it goes without stopping 1 minute with patch: https://cygwin.com/ml/cygwin-patches/2020-q1/msg00148.html In any case, the following error occurs. /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld:test00.d: file format not recognized; treating as linker script /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld:test00.d:1: syntax error collect2: error: ld returned 1 exit status make: *** [: hang] Error 1 make: *** Waiting for unfinished jobs Is this as you expected? -- Takashi Yano -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On 11/02/2020 07:58, Peter Dons Tychsen wrote: It seems to be related to the fact the is is spawning non-cygwin programs. If i do the same test with normal GCC (default cygwin gcc) then everything is fine. That's great work, and I can confirm that it is the same in my environment. Our makefiles start the following: * Several cygwin utilities (e.g. cygpath, cut, sed, etc.) * Linux cross-compilers/linkers that are cygwin programmes * Windows native compilers/linkers (not cygwin) * HPE Nonstop cross-compilers/linkers (not cygwin) So what you've found is consistent with the issue that we're getting. 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi all, On Thu, 2020-02-06 at 09:18 +1100, David Finnie wrote: > That would be awesome if you could create a small test case OK, i put together a test-case: 1) Put attached makefile somewhere 2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe and unzip it in same place. 3) Now run "make create" 4) Now run "make clean && make -j32". Try a couple of times. --- a) If running via mintty - it hangs fairly quickly, and the task- manager will show hanging gcc's and sh's. b) If running in normal terminal via "bash --login" shortcut, everything is ok. Ran 100s of times with no error. --- It seems to be related to the fact the is is spawning non-cygwin programs. If i do the same test with normal GCC (default cygwin gcc) then everything is fine. My guess would be that this is related to the pseudo-console changes. I think it relates to an terminal I/O problem when the tasks are starting/stopping. Thanks, /pedro test: hang define test test$(1).d: test$(1).c echo running thread $(1) MinGW/bin/gcc -MP -MM -MT $$@ -M -o $$@ $$^ &&\ MinGW/bin/gcc -c -o $$(^:.c=.o) $$^ outputs += test$(i).d inputs += test$(i).c endef loops := 0 1 2 3 4 5 6 7 8 9 loops := $(foreach i, $(loops),$(i)0 $(i)1 $(i)2 $(i)3 $(i)4 $(i)5 $(i)6 $(i)7 $(i)8 $(i)9) $(foreach i,$(loops),$(eval $(call test,$(i hang: $(outputs) print: echo $(outputs) echo $(inputs) %.c: echo "#include " > $@ echo "#include " >> $@ echo "#include " >> $@ create: $(inputs) echo clean: rm -rf *.c *.d *.o -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On 8/02/2020 05:13, Brian Inglis wrote: DF's post immediately preceding that KB post at the start of*January* *was* Brian, indeed. And, as I'm sure you're aware - given that you were trawling through past posts - Ken already pulled me up on it, and since then I haven't. It has been my *only* top post to the list. https://cygwin.com/ml/cygwin/2020-01/msg00022.html I sent this latest message because Ken *again* pulled me up on it, even though I haven't done it since. As I mentioned, if this is a "rule" for the list, then it should be mentioned in the "Reporting guidelines" here: https://cygwin.com/problems.html I would not have done it in the first place if it was mentioned there, because I did carefully read that prior to my first post. -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On 2020-02-05 16:35, Ken Brown wrote: > On 2/5/2020 6:07 PM, David Finnie wrote: >>> [Please don't top-post on this list. Thanks.] >> What do you mean by top posting, then ? How was my post a top post ? > It wasn't. I misread it. Sorry. DF's post immediately preceding that KB post at the start of *January* *was* TOFU: https://cygwin.com/ml/cygwin/2020-01/msg00021.html -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On Wed, 5 Feb 2020 17:07:38 -0500 Ken Brown wrote: > That last issue is probably due to changes in > /usr/bin/cygwin-console-helper.exe > related to the new PTY code. So in addition to rewinding the DLL, you have > to > rewind cygwin-console-helper. Indeed, cygwin-console-helper.exe was changed related to the pseudo console support, however, it suppose to be upper compatible. At least cygwin 3.0.7 works with new cygwin-console-helper.exe. -- Takashi Yano -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On 2/5/2020 6:07 PM, David Finnie wrote: [Please don't top-post on this list. Thanks.] What do you mean by top posting, then ? How was my post a top post ? It wasn't. I misread it. Sorry. Ken -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
[Please don't top-post on this list. Thanks.] What do you mean by top posting, then ? How was my post a top post ? Thanks. 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
[Please don't top-post on this list. Thanks.] On 2/5/2020 5:18 PM, David Finnie wrote: Hi Pedro, I have started down the road of building cygwin, but did run into a few issues so don't have a debuggable version yet. If you beat me to it, please let me know. Thanks! Any findings? Unfortunately no, I did get a clean build, but "make install" following it just created complete havoc in my cygwin environment (lots of errors indicating that a rebase was required, but rebasing didn't fix them). Reinstalls of the cygwin base dll (and other packages) didn't fix it, and I was forced to delete my entire cygwin directory and reinstall all cygwin packages that I needed from scratch. I'm not inclined to go through that pain again any time soon. You should build as suggested in https://www.cygwin.com/faq.html#faq.programming.building-cygwin so that "make install" installs everything into a temporary location from which you can copy what you need. Ken -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi Pedro, I have started down the road of building cygwin, but did run into a few issues so don't have a debuggable version yet. If you beat me to it, please let me know. Thanks! Any findings? Unfortunately no, I did get a clean build, but "make install" following it just created complete havoc in my cygwin environment (lots of errors indicating that a rebase was required, but rebasing didn't fix them). Reinstalls of the cygwin base dll (and other packages) didn't fix it, and I was forced to delete my entire cygwin directory and reinstall all cygwin packages that I needed from scratch. I'm not inclined to go through that pain again any time soon. I have on my to-do list to use the cygwin time machine, as Ken suggested, and will try to isolate when the problem first appeared. However, my day job has been getting in the way on that, so I haven't yet found the time. For the moment, I'm continuing to run on 3.0.7 without any issues. I have found something interesting: 1) If i run the terminal without mintty, the problem goes away. I can run my makefiles with "make -j20" without any issues if i start with "bash --login" instead of the mintty shortcut, where it just uses the normal windows terminal. 2) As soon as i run via mintty, even "make -j2" quickly goes south, causes various fork() issues as we have seen. I will see if i can create a small makefile that shows this. That would be awesome if you could create a small test case. 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On 2/5/2020 4:45 PM, Peter Dons Tychsen wrote: Hi David & Co, I have started down the road of building cygwin, but did run into a few issues so don't have a debuggable version yet. If you beat me to it, please let me know. Thanks! Any findings? I have found something interesting: 1) If i run the terminal without mintty, the problem goes away. I can run my makefiles with "make -j20" without any issues if i start with "bash --login" instead of the mintty shortcut, where it just uses the normal windows terminal. 2) As soon as i run via mintty, even "make -j2" quickly goes south, causes various fork() issues as we have seen. I will see if i can create a small makefile that shows this. So either the change we are looking for affects mintty, or the actual bug we are looking for is in mintty and not the DLL (or both). Can anyone shed light on this? Another problem is that if i rewind the DLL (building previous commits) too much then mintty stops working... That last issue is probably due to changes in /usr/bin/cygwin-console-helper.exe related to the new PTY code. So in addition to rewinding the DLL, you have to rewind cygwin-console-helper. Ken -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi David & Co, > I have started down the road of building cygwin, but did run into a > few issues so don't have a debuggable version yet. If you beat me to > it, please let me know. Thanks! Any findings? I have found something interesting: 1) If i run the terminal without mintty, the problem goes away. I can run my makefiles with "make -j20" without any issues if i start with "bash --login" instead of the mintty shortcut, where it just uses the normal windows terminal. 2) As soon as i run via mintty, even "make -j2" quickly goes south, causes various fork() issues as we have seen. I will see if i can create a small makefile that shows this. So either the change we are looking for affects mintty, or the actual bug we are looking for is in mintty and not the DLL (or both). Can anyone shed light on this? Another problem is that if i rewind the DLL (building previous commits) too much then mintty stops working... Any pointers would be great! Thanks, /pedro -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
[Please don't top-post on this list. Thanks.] On 1/2/2020 5:29 PM, David Finnie wrote: > Hi Pedro, > > That's good to hear confirmation. > > I have started down the road of building cygwin, but did run into a few > issues so don't have a debuggable version yet. If you beat me to it, > please let me know. Thanks! You could also try the various test releases between cygwin-3.0.7 and cygwin-3.1.0 using the Cygwin Time Machine. See https://cygwin.com/ml/cygwin/2020-01/msg00018.html Ken -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi Pedro, That's good to hear confirmation. I have started down the road of building cygwin, but did run into a few issues so don't have a debuggable version yet. If you beat me to it, please let me know. Thanks! Dave On Fri, 3 Jan. 2020, 08:58 Peter Dons Tychsen, wrote: > Hi Cygwinners, > > On Thu, 2020-01-02 at 10:43 +1100, David Finnie wrote: > > 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. > > I second this. I have the exact same problem on some of my setups. > Reverting to 3.0.7-1 also fixes it for me. Without reverting i get > stuck in processes all the time (especially with make -jx). Also the > slowdown seems apparent here, even though that is not my biggest > concern ATM, but hanging build servers are :-). > > My guess would also be the fork changes, even though i have zero proof > so far. Have not had time to debug. > > Thanks, > > /pedro > > -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Hi Cygwinners, On Thu, 2020-01-02 at 10:43 +1100, David Finnie wrote: > 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. I second this. I have the exact same problem on some of my setups. Reverting to 3.0.7-1 also fixes it for me. Without reverting i get stuck in processes all the time (especially with make -jx). Also the slowdown seems apparent here, even though that is not my biggest concern ATM, but hanging build servers are :-). My guess would also be the fork changes, even though i have zero proof so far. Have not had time to debug. Thanks, /pedro -- 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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
On 1/1/2020 6:43 PM, David Finnie wrote:
> 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 !).
You could try building cygwin with DEBUGGING0 defined to see if this is where
the EAGAIN is coming from. I think the error message would show up in strace
output, so you'd have to be able to reproduce the problem under strace.
And it would be great if you could find a testcase that you can share with the
list, so that others can try to reproduce the problem.
Ken
--
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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
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
Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
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? > Some example error output from make: > > make[2]: ../../build/Make/platform_options.mk:9: fork: Resource temporarily > unavailable > make[2]: ../../build/Make/platform_options_linux.mk:33: fork: Resource > temporarily unavailable > make[2]: ../../build/Make/platform_options.mk:9: fork: Resource temporarily > unavailable > make[2]: ../../build/Make/platform_options_linux.mk:33: fork: Resource > temporarily unavailable > make[2]: ../../build/Make/platform_options_oss_l.mk:7: fork: Resource > temporarily unavailable > make[2]: fork: Resource temporarily unavailable > > Note that while some make operations fail as per above, the vast majority > work - > including sub-makes that are executing the exact same lines that occasionally > fail. If I force make to run with 1 concurrent job (-j1), I don't get these > errors. > > I have confirmed via Windows Task Manager that the correct cygwin64 make and > bash are being invoked. The makefiles do not override the default SHELL. > > I have tried all of the usual things: > > - running rebaseall from ash (running as Administrator) > > - using rebase-trigger full, and then re-running cygwin64 setup > > - reverting to a slightly older version of make and bash Have you tried reverting to cygwin-3.0.7-1? > This all happened immediately after upgrading the cygwin installation, and I > didn't change anything else on my system in between make working perfectly, > and > now consistently getting these errors. > > Is anyone else experiencing this ? Does anyone have any further magic to try > to > correct it ? > > cygcheck.out attached. 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. Ken -- 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
fork: Resource temporarily unavailable errors after upgrading cygwin packages
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). Some example error output from make: make[2]: ../../build/Make/platform_options.mk:9: fork: Resource temporarily unavailable make[2]: ../../build/Make/platform_options_linux.mk:33: fork: Resource temporarily unavailable make[2]: ../../build/Make/platform_options.mk:9: fork: Resource temporarily unavailable make[2]: ../../build/Make/platform_options_linux.mk:33: fork: Resource temporarily unavailable make[2]: ../../build/Make/platform_options_oss_l.mk:7: fork: Resource temporarily unavailable make[2]: fork: Resource temporarily unavailable Note that while some make operations fail as per above, the vast majority work - including sub-makes that are executing the exact same lines that occasionally fail. If I force make to run with 1 concurrent job (-j1), I don't get these errors. I have confirmed via Windows Task Manager that the correct cygwin64 make and bash are being invoked. The makefiles do not override the default SHELL. I have tried all of the usual things: - running rebaseall from ash (running as Administrator) - using rebase-trigger full, and then re-running cygwin64 setup - reverting to a slightly older version of make and bash This all happened immediately after upgrading the cygwin installation, and I didn't change anything else on my system in between make working perfectly, and now consistently getting these errors. Is anyone else experiencing this ? Does anyone have any further magic to try to correct it ? cygcheck.out attached. Thanks in advance ! Dave Cygwin Configuration Diagnostics Current System Time: Mon Dec 30 01:40:21 2019 Windows 10 Home Ver 10.0 Build 18362 Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Python38\Scripts C:\Python38 C:\Program Files (x86)\Common Files\Oracle\Java\javapath C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files\Microsoft DNX\Dnvm C:\Program Files\Microsoft SQL Server\130\Tools\Binn C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn C:\Program Files\Microsoft SQL Server\110\Tools\Binn C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0 C:\Program Files\Microsoft SQL Server\120\Tools\Binn C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\WINDOWS\System32\OpenSSH C:\Program Files (x86)\Java\jre1.8.0_181\bin C:\Program Files (x86)\Java\jdk1.6.0_20\bin C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR C:\Program Files (x86)\Bitvise SSH Client C:\Program Files\PuTTY C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL C:\Program Files\Intel\Intel(R) Management Engine Components\DAL C:\Program Files\SafeNet\Authentication\SAC\x64 C:\Program Files\SafeNet\Authentication\SAC\x32 C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\WINDOWS\System32\OpenSSH C:\Program Files\TortoiseGit\bin C:\Program Files\Git\cmd C:\Program Files\CMake\bin C:\ProgramData\chocolatey\bin C:\Program Files\TortoiseSVN\bin . C:\Program Files\Conan\conan C:\MinGW\msys\1.0\bin C:\python27 C:\cygwin64\bin C:\Users\Dave\AppData\Local\Microsoft\WindowsApps D:\users\dave\bin C:\python27\scripts D:\nsdee_7.1_64\eclipse Output from C:\cygwin64\bin\id.exe UID: 197609(Dave) GID: 197121(None) 197121(None) 559(Performance Log Users) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users) 15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication)401408(Medium Mandatory Level) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'Dave' PWD = '/cygdrive/c/cygwin/home/dave/infrasoft/dev/AFL' HOME = '/cygdrive/c/cygwin/home/dave' USERDOMAIN = 'ALIEN-I9' OS = 'Windows_NT' VS90COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual S
Re: fork: Resource temporarily unavailable: address space is already occupied
Christopher Faylor writes: On Thu, Aug 11, 2011 at 05:07:15AM +, Heiko Elger wrote: Ryan Johnson writes: Let me ask again, what was being compiled when the problems arose? And is it an intermittent error or a consistent one? I'm sorry - I havn't seen your question. The error is intermittent. Sometimes I have this error and sometimes not - really not reproduceable. If it occurs - it's always while compiling another sourcefile. What is compiled: C-Files. We use VxWorks GNU-MinGW Crosscompiler by (Wind River Systems). The make is an old cygwin (1.5.x) make-3.80 and the sh is a cygwin (1.5.x) by Wind River Systems. This is certainly an unsupported configuration. Contact Wind River if you want support. What is unsupported - using old cygwin 1.5.x binaries ? OK - using 1.5.x binaries is not supported - but it should work? Or not? If you mean WindRiver MinGW Gnu Compiler - not supported (yes, of course) - but it' only a win32 (non cygwin program) and I was asked what's running ... heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
On 8/11/2011 10:02 AM, Heiko Elger wrote: Christopher Faylor writes: On Thu, Aug 11, 2011 at 05:07:15AM +, Heiko Elger wrote: Ryan Johnson writes: Let me ask again, what was being compiled when the problems arose? And is it an intermittent error or a consistent one? I'm sorry - I havn't seen your question. The error is intermittent. Sometimes I have this error and sometimes not - really not reproduceable. If it occurs - it's always while compiling another sourcefile. What is compiled: C-Files. We use VxWorks GNU-MinGW Crosscompiler by (Wind River Systems). The make is an old cygwin (1.5.x) make-3.80 and the sh is a cygwin (1.5.x) by Wind River Systems. that is unsupported. If you receive your cygwin from WindRiver, ask WindRiver. If the fault is from WindRiver MinGW Gnu Compiler also ask them. This is certainly an unsupported configuration. Contact Wind River if you want support. What is unsupported - using old cygwin 1.5.x binaries ? OK - using 1.5.x binaries is not supported - but it should work? Or not? cygwin-1.5.x binaries run on cygwin-1.7.x. cygwin-1.7.x is supported cygwin-1.5.x is not supported anymore, see note on http://cygwin.com/index.html If you mean WindRiver MinGW Gnu Compiler - not supported (yes, of course) - but it' only a win32 (non cygwin program) and I was asked what's running ... heiko Marco -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
Christopher Faylor writes: On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote: Hello, I know there are lots of such postings Resource temporarily unavailable. But using lates snapshot (2011-08-03): there are changes by C. Faylor printing cause of fork failure. I can see I'm going to regret exposing these errors. They have been there for a couple of months but they were strace only. I just made them more visible. This. Is a recording. rebaseall and peflagsall should fix the problem. After rebaseall and peflagsall, I will get the following errors while running make -j *** snip snip snip * abnormal program termination C:\TEMP\make556888.sh: fork failed: no child processes [1] *** snip snip snip * Any other hints? best regards Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
On 10/08/2011 7:04 AM, Heiko Elger wrote: Christopher Faylor writes: On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote: Hello, I know there are lots of such postings Resource temporarily unavailable. But using lates snapshot (2011-08-03): there are changes by C. Faylor printing cause of fork failure. I can see I'm going to regret exposing these errors. They have been there for a couple of months but they were strace only. I just made them more visible. This. Is a recording. rebaseall and peflagsall should fix the problem. After rebaseall and peflagsall, I will get the following errors while running make -j *** snip snip snip * abnormal program termination C:\TEMP\make556888.sh: fork failed: no child processes [1] *** snip snip snip * Any other hints? Did you reboot? Windows won't notice the changes made by peflagsall until you do so. Also, you never mentioned what you are making. Are you, by chance building an app which builds helper binaries and/or lots of shared libraries? Apps such as emacs, gcc, and perl are a few examples. BTW, I don't recognize that particular error message. CGF, does it mean anything significant? Ryan -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
Heiko Elger writes: Christopher Faylor writes: On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote: Hello, I know there are lots of such postings Resource temporarily unavailable But using lates snapshot (2011-08-03): there are changes by C. Faylor printing cause of fork failure. I can see I'm going to regret exposing these errors. They have been there for a couple of months but they were strace only. I just made them more visible. This. Is a recording. rebaseall and peflagsall should fix the problem. After rebaseall and peflagsall, I will get the following errors while running make -j *** snip snip snip * abnormal program termination C:\TEMP\make556888.sh: fork failed: no child processes [1] *** snip snip snip * I forgot, is it possible a error of make? I use old make 3.80 (binary from cygwin 1.5.x) .. .. and I do not run rebase/peflags against it. Is it allowed to run old make (see http://thread.gmane.org/gmane.os.cygwin /128011) best regards Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
Ryan Johnson writes: Did you reboot? Windows won't notice the changes made by peflagsall until you do so. yes Also, you never mentioned what you are making. Are you, by chance building an app which builds helper binaries and/or lots of shared libraries? Apps such as emacs, gcc, and perl are a few examples. No other application is running with the exception of perl (for scanning/starting new jobs). The system is used as a compile machine. regras Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
On 10/08/2011 7:16 AM, Heiko Elger wrote: Ryan Johnson writes: Did you reboot? Windows won't notice the changes made by peflagsall until you do so. yes Also, you never mentioned what you are making. Are you, by chance building an app which builds helper binaries and/or lots of shared libraries? Apps such as emacs, gcc, and perl are a few examples. No other application is running with the exception of perl (for scanning/starting new jobs). The system is used as a compile machine. Let me ask again, what was being compiled when the problems arose? And is it an intermittent error or a consistent one? Ryan -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
Ryan Johnson writes: Let me ask again, what was being compiled when the problems arose? And is it an intermittent error or a consistent one? I'm sorry - I havn't seen your question. The error is intermittent. Sometimes I have this error and sometimes not - really not reproduceable. If it occurs - it's always while compiling another sourcefile. What is compiled: C-Files. We use VxWorks GNU-MinGW Crosscompiler by (Wind River Systems). The make is an old cygwin (1.5.x) make-3.80 and the sh is a cygwin (1.5.x) by Wind River Systems. regrads Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
On Thu, Aug 11, 2011 at 05:07:15AM +, Heiko Elger wrote: Ryan Johnson writes: Let me ask again, what was being compiled when the problems arose? And is it an intermittent error or a consistent one? I'm sorry - I havn't seen your question. The error is intermittent. Sometimes I have this error and sometimes not - really not reproduceable. If it occurs - it's always while compiling another sourcefile. What is compiled: C-Files. We use VxWorks GNU-MinGW Crosscompiler by (Wind River Systems). The make is an old cygwin (1.5.x) make-3.80 and the sh is a cygwin (1.5.x) by Wind River Systems. This is certainly an unsupported configuration. Contact Wind River if you want support. -- 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
fork: Resource temporarily unavailable: address space is already occupied
Hello, I know there are lots of such postings Resource temporarily unavailable. But using lates snapshot (2011-08-03): there are changes by C. Faylor printing cause of fork failure. I've gotten the following error message while running make in parallel using (make -j8). 0 [main] sh 8 child_info_fork::abort: address space needed by 'cyggcc_s-1.dll' (67F0) is already occupied c:/programme/cygwin/bin/sh: fork: Resource temporarily unavailable The question is: Is there somethink I can to to avoid this error? Why is this address already occupied? There are losts of postings about rebaseall, peflagsall ... My system Win7/64, Intel Xeon CPU, 12MB RAM. uname -a -- CYGWIN_NT-6.1-WOW64 PC01028 1.7.10s(0.249/5/3) 20110803 18:07:45 i686 Cygwin Please can anyone give me a hint. best regards Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote: Hello, I know there are lots of such postings Resource temporarily unavailable. But using lates snapshot (2011-08-03): there are changes by C. Faylor printing cause of fork failure. I can see I'm going to regret exposing these errors. They have been there for a couple of months but they were strace only. I just made them more visible. This. Is a recording. rebaseall and peflagsall should fix the problem. cgf -- 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
Re: Fork: Resource temporarily unavailable
2008/6/16 Larry Hall (Cygwin) [EMAIL PROTECTED]: A common reason for this kind of message is also http://cygwin.com/acronyms/#BLODA. Check it out if you haven't already. Thanks Larry- I've taken a look at the list, and the only match with our environment is McAfee - but that doesn't explain why some servers run just fine with it, while others develop a problem. I'm currently thinking that most of the issues are seen on Citrix Metaframe Presentation Servers, after they've had the following CTX hotfixes installed: PSE400W2K3R04 PSE400R04W2K3001 PSE400R04W2K3002 PSE400R04W2K3007 PSE400R04W2K3011 PSE400R04W2K3039 - It's still confusing, as it seems to affect around 80% of such servers, whilst the remaining 20% carry on just fine. The issue also seems to affect some servers when a lower hotfix level has been applied. For the moment, I'm going to concentrate on the Citrix angle, and put the other miscellaneous servers (SQL or Exchange) to one side and consider them likely to be a separate issue with similar symptoms. I'm currently re-investigating the CPU and memory optimization features in case I missed something previously. -- AdamT At times one remains faithful to a cause only because its opponents do not cease to be insipid. - Nietzsche -- 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/
Fork: Resource temporarily unavailable
Dear all, We have several sshd installations based on Cygwin, running on Server 2003 SP1 (and also SP2). Over the last 12 months or so, there seems to have been a lot of problems with sshd - the eventlogs cite a fork: resource temporarily unavailable - error. I've checked the obvious (ie port 22/tcp isn't already bound elsewhere, ran filemon/regmon) but failed to find the reason. Is there a way of logging _which_ resource is temporarily (or rather, persistently) unavailable? There seems to be a higher occurrence of this issue on Citrix PS 4.0/4.5 presentation servers, but after ruling out various memory and cpu optimisations (eg DLL rebasing - I've tried the rebaseall script and confirmed that none of the sshd or cygrunsrv dependencies have been touched by Citrix MPS), I can't pin it down to a specific patch level or configuration. I've seen various other threads relating to this issue, but no solution. I'd like to find the solution, but I seem to be missing some vital pieces of the puzzle. I have a nasty feeling this is going to involve learning a bit more about understanding the drwtsn32.exe crashdumps (manually attaching the debugger, as crashdumps aren't a symptom of this issue). Thanks in advance - for any pointers/hints, -- AdamT At times one remains faithful to a cause only because its opponents do not cease to be insipid. - Nietzsche -- 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/
Re: Fork: Resource temporarily unavailable
Adam Thompson wrote: Dear all, We have several sshd installations based on Cygwin, running on Server 2003 SP1 (and also SP2). Over the last 12 months or so, there seems to have been a lot of problems with sshd - the eventlogs cite a fork: resource temporarily unavailable - error. I've checked the obvious (ie port 22/tcp isn't already bound elsewhere, ran filemon/regmon) but failed to find the reason. Is there a way of logging _which_ resource is temporarily (or rather, persistently) unavailable? There seems to be a higher occurrence of this issue on Citrix PS 4.0/4.5 presentation servers, but after ruling out various memory and cpu optimisations (eg DLL rebasing - I've tried the rebaseall script and confirmed that none of the sshd or cygrunsrv dependencies have been touched by Citrix MPS), I can't pin it down to a specific patch level or configuration. I've seen various other threads relating to this issue, but no solution. I'd like to find the solution, but I seem to be missing some vital pieces of the puzzle. I have a nasty feeling this is going to involve learning a bit more about understanding the drwtsn32.exe crashdumps (manually attaching the debugger, as crashdumps aren't a symptom of this issue). Thanks in advance - for any pointers/hints, A common reason for this kind of message is also http://cygwin.com/acronyms/#BLODA. Check it out if you haven't already. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/
RE: xargs: cannot fork: Resource temporarily unavailable
Thanks Larry it was after all still the Logitech crap... I thought just by disabling its two services on the Windows Service manager that it was sufficient, but then the Logitech serice mentioned in that url was not one of them... So I completely removed it and voila!! :-) Thanks again Jose Correia -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Hall (Cygwin) Sent: 23 November 2007 06:14 AM To: cygwin@cygwin.com Subject: Re: xargs: cannot fork: Resource temporarily unavailable Jose Correia wrote: Hi all Sometime ago I posted saying it could have been the Logitech services running, as I had read somewhere on the mailing list, but unfortunately that is not the case, the problem below still persists... Can someone shed some urgent light on this matter please? Got BLODA? ;-) http://cygwin.com/acronyms/#BLODA This is a typical cause of stuff like this. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/ -- 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/
Re: xargs: cannot fork: Resource temporarily unavailable
Jose Correia wrote: Hi all Sometime ago I posted saying it could have been the Logitech services running, as I had read somewhere on the mailing list, but unfortunately that is not the case, the problem below still persists... Can someone shed some urgent light on this matter please? Got BLODA? ;-) http://cygwin.com/acronyms/#BLODA This is a typical cause of stuff like this. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/
RE: xargs: cannot fork: Resource temporarily unavailable
Hi all
Sometime ago I posted saying it could have been the Logitech services
running, as I had read somewhere on the mailing list, but unfortunately
that is not the case, the problem below still persists... Can someone
shed some urgent light on this matter please?
Appreciated
Jose Correia
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Jose Correia
Sent: 12 November 2007 03:55 PM
To: cygwin@cygwin.com
Subject: xargs: cannot fork: Resource temporarily unavailable
Hi all
Im using cygin install when the cygwin install version 2.457.2.2 on
Windows XP professional SP2, on an IBM ThinkPad Dual Processor T60.
I run a unix script from a bigger ant script, which used to work fine on
a single processor laptop. Now it works intermittently
The Unix script is this:
#START
export SRC=$1
find $SRC -type d -name 'CVS' | xargs -i rm -rf {}
mv $SRC/tres/src/java/com/traderoot/core/
$SRC/tres/src/java/com/traderoot/cfgcore
#for jaxb generated source
mv $SRC/com/traderoot/core/ $SRC/com/traderoot/cfgcore
grep -Rl 'com.traderoot.core' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.core/com.traderoot.cfgcore/g' {} grep -Rl
'com/traderoot/core' $SRC | xargs -i ./replace.sh
's#com/traderoot/core#com/traderoot/cfgcore#g' {} grep -Rl
'com.traderoot.tools' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' {}
#END
On the times when it does not work it spews out:
[exec] + xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' '{}'
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Additionaldata.jav
a
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Address.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Arg.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/impl/JAXBVersion.j
ava
[exec] 4 [main] xargs 112660 fork_copy: linked dll data/bss
pass 0 failed, 0x54D000..0x54D020, done 0, windows pid 114584, Win32
error 487
[exec] xargs: cannot fork: Resource temporarily unavailable
Could this be because of the dual processor where somehow the one
process is left hanging waiting for the other? Anyone experienced this
issue before...? can't find anything on the archives...
Regards
Jose Correia
--
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/
--
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/
xargs: cannot fork: Resource temporarily unavailable
Hi all
Im using cygin install when the cygwin install version 2.457.2.2 on
Windows XP professional SP2, on an IBM ThinkPad Dual Processor T60.
I run a unix script from a bigger ant script, which used to work fine on
a single processor laptop. Now it works intermittently
The Unix script is this:
#START
export SRC=$1
find $SRC -type d -name 'CVS' | xargs -i rm -rf {}
mv $SRC/tres/src/java/com/traderoot/core/
$SRC/tres/src/java/com/traderoot/cfgcore
#for jaxb generated source
mv $SRC/com/traderoot/core/ $SRC/com/traderoot/cfgcore
grep -Rl 'com.traderoot.core' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.core/com.traderoot.cfgcore/g' {}
grep -Rl 'com/traderoot/core' $SRC | xargs -i ./replace.sh
's#com/traderoot/core#com/traderoot/cfgcore#g' {}
grep -Rl 'com.traderoot.tools' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' {}
#END
On the times when it does not work it spews out:
[exec] + xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' '{}'
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Additionaldata.jav
a
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Address.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Arg.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/impl/JAXBVersion.j
ava
[exec] 4 [main] xargs 112660 fork_copy: linked dll data/bss
pass 0 failed, 0x54D000..0x54D020, done 0, windows pid 114584, Win32
error 487
[exec] xargs: cannot fork: Resource temporarily unavailable
Could this be because of the dual processor where somehow the one
process is left hanging waiting for the other? Anyone experienced this
issue before...? can't find anything on the archives...
Regards
Jose Correia
--
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/
RE: xargs: cannot fork: Resource temporarily unavailable
Damn formatting, the greps are each on a separate line.
I did some more research and via Google I found that the recently
installed Logitech Webcam software might be clashing with it, I disabled
it and so far ok, will let u know.
The mailing list search did not return anything when I searched for
xargs: cannot fork: Resource temporarily unavailable hence why I said
I had found nothing. Had I limited the search further to cannot fork:
Resource temporarily unavailable I would have found something. ;-)
Regards
Jose
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Jose Correia
Sent: 12 November 2007 03:55 PM
To: cygwin@cygwin.com
Subject: xargs: cannot fork: Resource temporarily unavailable
Hi all
Im using cygin install when the cygwin install version 2.457.2.2 on
Windows XP professional SP2, on an IBM ThinkPad Dual Processor T60.
I run a unix script from a bigger ant script, which used to work fine on
a single processor laptop. Now it works intermittently
The Unix script is this:
#START
export SRC=$1
find $SRC -type d -name 'CVS' | xargs -i rm -rf {}
mv $SRC/tres/src/java/com/traderoot/core/
$SRC/tres/src/java/com/traderoot/cfgcore
#for jaxb generated source
mv $SRC/com/traderoot/core/ $SRC/com/traderoot/cfgcore
grep -Rl 'com.traderoot.core' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.core/com.traderoot.cfgcore/g' {} grep -Rl
'com/traderoot/core' $SRC | xargs -i ./replace.sh
's#com/traderoot/core#com/traderoot/cfgcore#g' {} grep -Rl
'com.traderoot.tools' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' {}
#END
On the times when it does not work it spews out:
[exec] + xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' '{}'
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Additionaldata.jav
a
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Address.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Arg.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/impl/JAXBVersion.j
ava
[exec] 4 [main] xargs 112660 fork_copy: linked dll data/bss
pass 0 failed, 0x54D000..0x54D020, done 0, windows pid 114584, Win32
error 487
[exec] xargs: cannot fork: Resource temporarily unavailable
Could this be because of the dual processor where somehow the one
process is left hanging waiting for the other? Anyone experienced this
issue before...? can't find anything on the archives...
Regards
Jose Correia
--
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/
--
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/
Re: fork: Resource temporarily unavailable
jamil egdemir wrote: Hi, While trying to install matplotlib using easy_install for python (see output below) I ran into the 'fork: Resource temporarily unavailable' problem. I've been searching for a few hours now on the web.. no luck. I've searched the mailing lists: http://sourceware.org/cgi-bin/search.cgi?q=fork+temporarily+unavailablecmd=Search%21form=extendedm=allps=10fmt=longwm=wrdsp=1sy=1wf=2221type=GroupBySite=noul=%2Fml%2Fcygwin%2F%25 leading me to this: http://sources.redhat.com/ml/cygwin/2005-09/msg00945.html Here is the current value of my HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\SubSystems key: %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=2048,6144,4096 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=32 The values for SharedSection have all been increased to values above the defaults as described in the post above.. no effect. I also found a few other posts which suggested turning off services and such and I've turned off everything I could (virus scanners, chat clients, etc...) with msconfig to no effect. Not sure how to proceed. I'm thinking of trying a cygwin snapshot... or backing off to a previous version of cygwin.. Will this help? What was the first version of cygwin where this problem popped up? Lately, the biggest cause of this kind of error is: http://cygwin.com/acronyms/#BLODA You typically need to uninstall the offending software to see a difference. Disabling/turning it off is usually not enough. You may also be lucky and find that it's just problem with DLL base address collisions (can't tell from the scant info given so far). If that's the case, you can install the 'rebase' package and read its README to find out how to clear this up. While you're at it, you may as well install the current Cygwin version. 1.5.19 is old and not supported by this list. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/
Re: A tale of ../libtool: fork: Resource temporarily unavailable issue.
Eric Blake schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ravi V on 10/31/2006 2:50 PM: A tale of ../libtool: fork: Resource temporarily unavailable issue (cygcheck output attached). make -j1 will also help most likely. -- Reini -- 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/
Re: A tale of ../libtool: fork: Resource temporarily unavailable issue.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ravi V on 10/31/2006 2:50 PM: A tale of ../libtool: fork: Resource temporarily unavailable issue (cygcheck output attached). Problem --- Builds using cygwin shell (sh) fail with ../libtool: fork: Resource temporarily unavailable error. This happens when building mysql, for example. The fork: Resource temporarily unavailable can appear for a variety of reasons. And based on traffic on this list, those reasons are usually due to buggy or invasive drivers that inject threads into all windows programs, interfering with cygwin's ability to map memory properly as it emulates forks. Try disabling your logitech webcam driver or mcafee virus scanner (those tend to be the two biggest culprits, although there are others), and see if it makes a difference. Found: C:\cygwin\usr\local\tools\i686_win32\ActivePerl-5.8\bin\perl.exe Found: C:\cygwin\bin\perl.exe Warning: C:\cygwin\usr\local\tools\i686_win32\ActivePerl-5.8\bin\perl.exe hides C:\cygwin\bin\perl.exe You may want to try using the cygwin perl instead of ActivePerl; that may be contributing to your issue, as ActivePerl does not respond as well to cygwin forks. bash 3.1-6 You may want to consider an upgrade. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFFSAh084KuGfSFAYARAoKmAKDTnzkWhO9feVmSt0JWQEWbiu6v7QCY3viz eF08xgLJYDFiGkv4mxemQA== =VtXu -END PGP SIGNATURE- -- 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/
Re: fork: Resource temporarily unavailable
The answers to Larry Hall's questions on my original posting are below. Andy Hall wrote: It seems that somewhere between cygwin 1.5.19-4 and 1.5.21-2 some change was made that causes this error. I have a bash script that is used to create a number of client processes that run in parallel and generate TCP/IP conversations with a remote server being tested This script can configure and run any number of these clients executing simultaneously. The clients can be either .exe files based on .NET or a JVM (.exe) running a Java-based client. These scripts run flawlessly on Linux or Solaris (java clients only) or on a Win2K Professional box running cygwin 1.5.19-4 (both java or .NET clients) They were also running flawlessly on a Win2K Server, until it got upgraded to cygwin 1.5.2.21-2. After that, the scripts run for a while until the message fork: Resource temporarily unavailable occurs, at which point there are all sorts of bizarre and unexplainable failures. If run for a reasonable amount of time these scripts will always result in this error message. The obvious question is, How can we revert the Win2K Server back to cygwin 1.5.2.19.4 so that we can continue to run tests from this machine? Alternatively, is there fix or patch available for this? I have attached the output of cygcheck for both machines. Larry Hall's questions: How does it run outside the terminal server? I did the experiment. Running from the console fails as well. Has the virus scanner been installed/updated on the server? How about recently installed Logitech drivers? Both of these have been implicated in fork-related failures. This is an out-of-the-box, vanilla W2K Server with up-to-date MS patches, simple CRT console and serial mouse. No A/V SW or special drivers. The only third party software installed is: 1. J2SE JDK 1.5 2. MS .NET Framework 1.1 3. MySQL (which is not running) 4. Secure Shell (which was not running in the above experiment) 5. Cygwin 1.5.2.21-2 Andy Hall KonaWare, Inc. www.konaware.com -- 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/
fork: Resource temporarily unavailable
It seems that somewhere between cygwin 1.5.19-4 and 1.5.21-2 some change was made that causes this error. I have a bash script that is used to create a number of client processes that run in parallel and generate TCP/IP conversations with a remote server being tested This script can configure and run any number of these clients executing simultaneously. The clients can be either .exe files based on .NET or a JVM (.exe) running a Java-based client. These scripts run flawlessly on Linux or Solaris (java clients only) or on a Win2K Professional box running cygwin 1.5.19-4 (both java or .NET clients) They were also running flawlessly on a Win2K Server, until it got upgraded to cygwin 1.5.2.21-2. After that, the scripts run for a while until the message fork: Resource temporarily unavailable occurs, at which point there are all sorts of bizarre and unexplainable failures. If run for a reasonable amount of time these scripts will always result in this error message. The obvious question is, How can we revert the Win2K Server back to cygwin 1.5.2.19.4 so that we can continue to run tests from this machine? Alternatively, is there fix or patch available for this? I have attached the output of cygcheck for both machines. w2ks.cygcheck.out Description: Binary data w2kp.cygcheck.out Description: Binary data -- 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/
Re: fork: Resource temporarily unavailable
Andy Hall wrote: It seems that somewhere between cygwin 1.5.19-4 and 1.5.21-2 some change was made that causes this error. I have a bash script that is used to create a number of client processes that run in parallel and generate TCP/IP conversations with a remote server being tested This script can configure and run any number of these clients executing simultaneously. The clients can be either .exe files based on .NET or a JVM (.exe) running a Java-based client. These scripts run flawlessly on Linux or Solaris (java clients only) or on a Win2K Professional box running cygwin 1.5.19-4 (both java or .NET clients) They were also running flawlessly on a Win2K Server, until it got upgraded to cygwin 1.5.2.21-2. After that, the scripts run for a while until the message fork: Resource temporarily unavailable occurs, at which point there are all sorts of bizarre and unexplainable failures. If run for a reasonable amount of time these scripts will always result in this error message. The obvious question is, How can we revert the Win2K Server back to cygwin 1.5.2.19.4 so that we can continue to run tests from this machine? Alternatively, is there fix or patch available for this? I have attached the output of cygcheck for both machines. How does it run outside the terminal server? Has the virus scanner been installed/updated on the server? How about recently installed Logitech drivers? Both of these have been implicated in fork-related failures. See the related thread in the last week: http://cygwin.com/ml/cygwin/2006-10/msg00645.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (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/
RE: random fork: Resource temporarily unavailable
Larry Hall wrote:
Mark Bartel wrote:
Larry Hall wrote:
[deletia]
This sounds like the same issue I was encountering. I can reproduce
it
on demand with:
[EMAIL PROTECTED] ~
$ find * -type f -exec grep foo {} /dev/null \;
6 [main] find 435884 fhandler_dev_zero::fixup_mmap_after_fork:
requested 0x48 != 0x0 mem alloc base 0x48, 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 0x100, errno 11
find: cannot fork: Resource temporarily unavailable
[EMAIL PROTECTED] ~
$
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/?
Yes, the error above is with the 20060529 snapshot.
However, yet another person who has encountered this problem emailed me
with a workaround, which seems to resolve the issue in my case. He had
encountered the problem himself, and he found
http://aslongas.pe.kr/tt/
which says to turn off the Logitech Process Monitor service, installed
with Logitech webcam software.
-Mark
--
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/
RE: random fork: Resource temporarily unavailable
--On 22 June 2006 06:35 -0700 Mark Bartel wrote: However, yet another person who has encountered this problem emailed me with a workaround, which seems to resolve the issue in my case. He had encountered the problem himself, and he found http://aslongas.pe.kr/tt/ which says to turn off the Logitech Process Monitor service, installed with Logitech webcam software. Possibly confirmed! As soon as I stop LvPrcSrv, the problems that I was having with sshd are cured. When I restart LvPrcSrv, the problems with sshd return. -- Robin Walker p7sdAHHSLUp4x.p7s Description: S/MIME cryptographic signature
Re: random fork: Resource temporarily unavailable
Robin Walker wrote: --On 22 June 2006 06:35 -0700 Mark Bartel wrote: However, yet another person who has encountered this problem emailed me with a workaround, which seems to resolve the issue in my case. He had encountered the problem himself, and he found http://aslongas.pe.kr/tt/ which says to turn off the Logitech Process Monitor service, installed with Logitech webcam software. Possibly confirmed! As soon as I stop LvPrcSrv, the problems that I was having with sshd are cured. When I restart LvPrcSrv, the problems with sshd return. No confirmation of this issue is necessary. It's a Logitech issue. -- 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/
Re: random fork: Resource temporarily unavailable
On Thu, Jun 22, 2006 at 11:22:34AM -0400, Larry Hall (Cygwin) wrote: Robin Walker wrote: --On 22 June 2006 06:35 -0700 Mark Bartel wrote: However, yet another person who has encountered this problem emailed me with a workaround, which seems to resolve the issue in my case. He had encountered the problem himself, and he found http://aslongas.pe.kr/tt/ which says to turn off the Logitech Process Monitor service, installed with Logitech webcam software. Possibly confirmed! As soon as I stop LvPrcSrv, the problems that I was having with sshd are cured. When I restart LvPrcSrv, the problems with sshd return. No confirmation of this issue is necessary. It's a Logitech issue. So, when will sshd be fixed? It seems to me that if cygwin wants to be taken seriously it should try to work nicely with other software!!! cgf -- 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/
Re: random fork: Resource temporarily unavailable
Christopher Faylor wrote: On Thu, Jun 22, 2006 at 11:22:34AM -0400, Larry Hall (Cygwin) wrote: Robin Walker wrote: --On 22 June 2006 06:35 -0700 Mark Bartel wrote: However, yet another person who has encountered this problem emailed me with a workaround, which seems to resolve the issue in my case. He had encountered the problem himself, and he found http://aslongas.pe.kr/tt/ which says to turn off the Logitech Process Monitor service, installed with Logitech webcam software. Possibly confirmed! As soon as I stop LvPrcSrv, the problems that I was having with sshd are cured. When I restart LvPrcSrv, the problems with sshd return. No confirmation of this issue is necessary. It's a Logitech issue. So, when will sshd be fixed? It seems to me that if cygwin wants to be taken seriously it should try to work nicely with other software!!! There's a special stealth project to integrate Logitech camera with ssh, so perps that try to break ssh can be photographed. These photos will be posted on the ssh.perps.com web site for all to see. Once this project is done, everything should just work. Of course, it's very hush-hush, so don't tell anyone or they'll close it down and cart it away in the middle of the night... This is a secure list, right? -- 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/
RE: random fork: Resource temporarily unavailable
-Original Message- From: Larry Hall (Cygwin) Sent: Thursday, June 22, 2006 1:39 PM To: cygwin@cygwin.com Subject: Re: random fork: Resource temporarily unavailable Christopher Faylor wrote: On Thu, Jun 22, 2006 at 11:22:34AM -0400, Larry Hall (Cygwin) wrote: Robin Walker wrote: --On 22 June 2006 06:35 -0700 Mark Bartel wrote: However, yet another person who has encountered this problem emailed me with a workaround, which seems to resolve the issue in my case. He had encountered the problem himself, and he found http://aslongas.pe.kr/tt/ which says to turn off the Logitech Process Monitor service, installed with Logitech webcam software. Possibly confirmed! As soon as I stop LvPrcSrv, the problems that I was having with sshd are cured. When I restart LvPrcSrv, the problems with sshd return. No confirmation of this issue is necessary. It's a Logitech issue. So, when will sshd be fixed? It seems to me that if cygwin wants to be taken seriously it should try to work nicely with other software!!! There's a special stealth project to integrate Logitech camera with ssh, so perps that try to break ssh can be photographed. These photos will be posted on the ssh.perps.com web site for all to see. Once this project is done, everything should just work. Of course, it's very hush-hush, so don't tell anyone or they'll close it down and cart it away in the middle of the night... This is a secure list, right? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 I don't have the Logitech crap on my box, and still, although rarely, I still get the fork error. It actually only happens when I minimize the Cygwin window and running a GIMP autogen.sh script. What now? Charli -- 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/
Re: random fork: Resource temporarily unavailable
On Thu, Jun 22, 2006 at 01:47:46PM -0400, Charli Li wrote: -Original Message- From: Larry Hall (Cygwin) Sent: Thursday, June 22, 2006 1:39 PM To: [EMAIL PROTECTED] Subject: Re: random fork: Resource temporarily unavailable Wow. How many times do we have to ask not to quote raw email addresses in the body of the message? Christopher Faylor wrote: On Thu, Jun 22, 2006 at 11:22:34AM -0400, Larry Hall (Cygwin) wrote: Robin Walker wrote: --On 22 June 2006 06:35 -0700 Mark Bartel wrote: However, yet another person who has encountered this problem emailed me with a workaround, which seems to resolve the issue in my case. He had encountered the problem himself, and he found http://aslongas.pe.kr/tt/ which says to turn off the Logitech Process Monitor service, installed with Logitech webcam software. Possibly confirmed! As soon as I stop LvPrcSrv, the problems that I was having ith sshd are cured. When I restart LvPrcSrv, the problems with sshd return. No confirmation of this issue is necessary. It's a Logitech issue. So, when will sshd be fixed? It seems to me that if cygwin wants to be taken seriously it should try to work nicely with other software!!! There's a special stealth project to integrate Logitech camera with ssh, so perps that try to break ssh can be photographed. These photos will be posted on the ssh.perps.com web site for all to see. Once this project is done, everything should just work. Of course, it's very hush-hush, so don't tell anyone or they'll close it down and cart it away in the middle of the night... This is a secure list, right? I don't have the Logitech crap on my box, and still, although rarely, I still get the fork error. It actually only happens when I minimize the Cygwin window and running a GIMP autogen.sh script. What now? Time for a special stealth GIMP autogen.sh project, sounds like. cgf -- 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/
Re: random fork: Resource temporarily unavailable
Christopher Faylor wrote: On Thu, Jun 22, 2006 at 01:47:46PM -0400, Charli Li wrote: -Original Message- From: Larry Hall (Cygwin) Sent: Thursday, June 22, 2006 1:39 PM To: [EMAIL PROTECTED] Subject: Re: random fork: Resource temporarily unavailable Wow. How many times do we have to ask not to quote raw email addresses in the body of the message? Ok, since I know my last suggestion went over like a lead balloon, how about this? Any time the mailer daemon sees what looks like a raw e-mail address in a message, it checks it's allowed senders list. If you aren't on it, it quarantines your message and makes you add yourself by testifying (under oath, if we can manage that ;-)) that you have CYMTNQREAIYR'd. That way all the first-timers would at least get a big loud warning about what they're doing, and after that it would be transparent (only bug a given individual once). Or we could just drop a hippo on everyone that breaks the rule. ;-) -- Matthew The spiralling shape will make you go insane! -- They Might Be Giants -- 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/
RE: random fork: Resource temporarily unavailable
-Original Message- From: mwoehlke Sent: Thursday, June 22, 2006 3:56 PM To: cygwin mailing list Subject: Re: random fork: Resource temporarily unavailable Christopher Faylor wrote: On Thu, Jun 22, 2006 at 01:47:46PM -0400, Charli Li wrote: -Original Message- From: Larry Hall (Cygwin) Sent: Thursday, June 22, 2006 1:39 PM To: cygwin mailing list Subject: Re: random fork: Resource temporarily unavailable Wow. How many times do we have to ask not to quote raw email addresses in the body of the message? Ok, since I know my last suggestion went over like a lead balloon, how about this? Any time the mailer daemon sees what looks like a raw e-mail address in a message, it checks it's allowed senders list. If you aren't on it, it quarantines your message and makes you add yourself by testifying (under oath, if we can manage that ;-)) that you have CYMTNQREAIYR'd. That way all the first-timers would at least get a big loud warning about what they're doing, and after that it would be transparent (only bug a given individual once). Or we could just drop a hippo on everyone that breaks the rule. ;-) -- Matthew The spiralling shape will make you go insane! -- They Might Be Giants Oh, sorry. That better? -- 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/
RE: random fork: Resource temporarily unavailable
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:
[EMAIL PROTECTED] ~
$ find * -type f -exec grep foo {} /dev/null \;
6 [main] find 435884 fhandler_dev_zero::fixup_mmap_after_fork:
requested 0x48 != 0x0 mem alloc base 0x48, 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 0x100, errno 11
find: cannot fork: Resource temporarily unavailable
[EMAIL PROTECTED] ~
$
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.
-Mark
--
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/
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
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:
[EMAIL PROTECTED] ~
$ find * -type f -exec grep foo {} /dev/null \;
6 [main] find 435884 fhandler_dev_zero::fixup_mmap_after_fork:
requested 0x48 != 0x0 mem alloc base 0x48, 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 0x100, errno 11
find: cannot fork: Resource temporarily unavailable
[EMAIL PROTECTED] ~
$
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/
random fork: Resource temporarily unavailable
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 -- 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/
RE: random fork: Resource temporarily unavailable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Linda Walsh Sent: Thursday, June 15, 2006 6:06 PM To: cygwin@cygwin.com Subject: random fork: Resource temporarily unavailable 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 Confirmed. This happens on Windows 2000 Service Pack 4, with the latest *stable* cygwin1.dll. It happens when I even run a configure script, or anything else. It's rare, you're right Linda, and it happens at any time (also a bit annoying). The temporary workaround for me is to just restart the whatever and get on with life. Charli -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Cygwin) iD8DBQFEke+CKGyf4JaPChgRAmVYAJ9vGJHdRWLLdzt/a9L55sY9ieJPGQCfZjV3 p7JbZsrfKOzXEadjSjsL6os= =x6lh -END PGP SIGNATURE- -- 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/
Re: random fork: Resource temporarily unavailable
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. -- 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/
Re: fork: Resource temporarily unavailable
Are you sure about that? Me memory is 1G total, what's recommended values for the parameter? I 'd like to try again. On 4/20/06, Alexander J. Herrmann [EMAIL PROTECTED] wrote: Ken Perl wrote: I follow the workaround and increase the values by adding two zero to each of 3 parameters of SharedSection=,,, but when I still got the same error like before, then I reboot my XP and saw the blue screen and can't boot the XP. Then the Cygwin problem has gone :) Serious your memory may be faulty which would make it a Hard- and not a software problem. On 4/15/06, Larry Hall (Cygwin) [EMAIL PROTECTED] wrote: Ken Perl wrote: when I make graphicviz2.8 on cygwin, I was blocked by the below fork error. I searched the cygwin mailing list archive, and didn't find any userful info could help me to solve the problem, any comments? Did you miss this one? http://sources.redhat.com/ml/cygwin/2005-09/msg00945.html -- 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/ -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- 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/ -- And God saidLet there be light.But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer. Alexander J. Herrmann Analyst/Programmer http://www.aiengine.org Email: [EMAIL PROTECTED] -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- 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/
Re: fork: Resource temporarily unavailable
I follow the workaround and increase the values by adding two zero to each of 3 parameters of SharedSection=,,, but when I still got the same error like before, then I reboot my XP and saw the blue screen and can't boot the XP. On 4/15/06, Larry Hall (Cygwin) [EMAIL PROTECTED] wrote: Ken Perl wrote: when I make graphicviz2.8 on cygwin, I was blocked by the below fork error. I searched the cygwin mailing list archive, and didn't find any userful info could help me to solve the problem, any comments? Did you miss this one? http://sources.redhat.com/ml/cygwin/2005-09/msg00945.html -- 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/ -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- 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/
fork: Resource temporarily unavailable
when I make graphicviz2.8 on cygwin, I was blocked by the below fork error. I searched the cygwin mailing list archive, and didn't find any userful info could help me to solve the problem, any comments? gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../lib/cdt -I/usr/local/includ e -g -O2 -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -Wpointe r-arith -Wall -ffast-math -MT edge.lo -MD -MP -MF .deps/edge.Tpo -c edge.c -o ed ge.o /dev/null 21 if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. ./.. -I../.. -I../../lib/cdt -I/usr/local/include -g -O2 -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -Wall -ffast-math -MT graph.lo -MD -MP -MF .deps/graph.Tpo -c -o graph.lo graph.c; \ then mv -f .deps/graph.Tpo .deps/graph.Plo; else rm -f .deps/graph.Tpo; ex it 1; fi 21 [main] sh 126676 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 28 [main] sh 126804 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 21 [main] sh 126840 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 11 [main] sh 126848 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 23 [main] sh 122000 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 23 [main] sh 126952 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- 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/
Re: fork: Resource temporarily unavailable
The problem is disappeared after my XP is rebooted. On 4/14/06, Ken Perl [EMAIL PROTECTED] wrote: when I make graphicviz2.8 on cygwin, I was blocked by the below fork error. I searched the cygwin mailing list archive, and didn't find any userful info could help me to solve the problem, any comments? gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../lib/cdt -I/usr/local/includ e -g -O2 -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -Wpointe r-arith -Wall -ffast-math -MT edge.lo -MD -MP -MF .deps/edge.Tpo -c edge.c -o ed ge.o /dev/null 21 if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. ./.. -I../.. -I../../lib/cdt -I/usr/local/include -g -O2 -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -Wall -ffast-math -MT graph.lo -MD -MP -MF .deps/graph.Tpo -c -o graph.lo graph.c; \ then mv -f .deps/graph.Tpo .deps/graph.Plo; else rm -f .deps/graph.Tpo; ex it 1; fi 21 [main] sh 126676 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 28 [main] sh 126804 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 21 [main] sh 126840 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 11 [main] sh 126848 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 23 [main] sh 122000 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 23 [main] sh 126952 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- 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/
Re: fork: Resource temporarily unavailable
but the problem came back again when I start the compling again, too sad. On 4/14/06, Ken Perl [EMAIL PROTECTED] wrote: The problem is disappeared after my XP is rebooted. On 4/14/06, Ken Perl [EMAIL PROTECTED] wrote: when I make graphicviz2.8 on cygwin, I was blocked by the below fork error. I searched the cygwin mailing list archive, and didn't find any userful info could help me to solve the problem, any comments? gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../lib/cdt -I/usr/local/includ e -g -O2 -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -Wpointe r-arith -Wall -ffast-math -MT edge.lo -MD -MP -MF .deps/edge.Tpo -c edge.c -o ed ge.o /dev/null 21 if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. ./.. -I../.. -I../../lib/cdt -I/usr/local/include -g -O2 -Wno-unused-parameter -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -Wall -ffast-math -MT graph.lo -MD -MP -MF .deps/graph.Tpo -c -o graph.lo graph.c; \ then mv -f .deps/graph.Tpo .deps/graph.Plo; else rm -f .deps/graph.Tpo; ex it 1; fi 21 [main] sh 126676 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 28 [main] sh 126804 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 21 [main] sh 126840 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 11 [main] sh 126848 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 23 [main] sh 122000 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable 23 [main] sh 126952 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: fork: Resource temporarily unavailable -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- perl -e 'print unpack(u,62V5N\FME;G\!EFQ`9VUA:6PN8V]M\[EMAIL PROTECTED] )' -- 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/
Re: fork: Resource temporarily unavailable
Hello, Ken Perl [EMAIL PROTECTED] wrote: On 4/14/06, Ken Perl [EMAIL PROTECTED] wrote: when I make graphicviz2.8 on cygwin, I was blocked by the below fork error. On 4/14/06, Ken Perl [EMAIL PROTECTED] wrote: The problem is disappeared after my XP is rebooted. but the problem came back again when I start the compling again, too sad. I had similar problems with my previous firewall (agnitum outpost), which I had to replace by another one. -- Luc Hermitte -- 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/
Re: fork: Resource temporarily unavailable
Ken Perl wrote: when I make graphicviz2.8 on cygwin, I was blocked by the below fork error. I searched the cygwin mailing list archive, and didn't find any userful info could help me to solve the problem, any comments? Did you miss this one? http://sources.redhat.com/ml/cygwin/2005-09/msg00945.html -- 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/
Re: informal report on fork: Resource temporarily unavailable incidents
On Mar 28 18:29, Tom Rodman wrote: Not expecting help, just sharing. We're running windows 2003 server enterprise edition on a quad processor HP proliant G3. uname -a results in [CYGWIN_NT-5.2 c7mdcs063 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin]. Yesterday I ran a script (kicked off in a makefile) to create /etc/passwd for a subset of users in our domain. It failed w/fork errors (see below). After the errors showed up I simplified the script by building and running a script like: #!/bin/bash mkpasswd -d -u username1 mkpasswd -d -u username2 mkpasswd -d -u username3 . . This script (search ahead for r7867) had about 400 uniq usernames. When I ran it on Monday it also failed w/fork errors on random lines. When the problem was happening there were ~105 processes running. net start|wc -l shows 66 services. what apparently fixed the problem: This Tuesday morning I came in, I resumed and then closed the vim sessions, closed the ssh sessions, then opened a new ssh session, and then ran the more complex script 100 times in a row and it never failed. Tonight I opened the same files in vim sessions, suspended them, and then ran the job once and it worked fine. We're rebooting the server tonight - it's been up just over 1 week. Should I try a later snapshot? That's always a good idea. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: informal report on fork: Resource temporarily unavailable incidents
On Wed, Mar 29, 2006 at 01:16:48PM +0200, Corinna Vinschen wrote: That's always a good idea. You sure? That sounds like maybe the next release would get some testing if that happens and, then, mailing list traffic might suffer. No, wait. It's ok. The sshd/cygwin/select is slow discussion will probably take up the slack. So, Corinna's right, by all means try a snapshot. cgf -- 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/
informal report on fork: Resource temporarily unavailable incidents
Not expecting help, just sharing.
We're running windows 2003 server enterprise edition on a quad processor
HP proliant G3. uname -a results in
[CYGWIN_NT-5.2 c7mdcs063 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin].
Yesterday I ran a script (kicked off in a makefile) to create /etc/passwd
for a subset of users in our domain. It failed w/fork errors (see below).
After the errors showed up I simplified the script by building
and running a script like:
#!/bin/bash
mkpasswd -d -u username1
mkpasswd -d -u username2
mkpasswd -d -u username3
.
.
This script (search ahead for r7867) had about 400 uniq usernames.
When I ran it on Monday it also failed w/fork errors on random lines.
When the problem was happening there were ~105 processes running.
net start|wc -l shows 66 services.
what apparently fixed the problem:
This Tuesday morning I came in, I resumed and then closed the vim
sessions, closed the ssh sessions, then opened a new ssh session,
and then ran the more complex script 100 times in a row and it never
failed. Tonight I opened the same files in vim sessions, suspended
them, and then ran the job once and it worked fine.
We're rebooting the server tonight - it's been up just over 1 week.
Should I try a later snapshot?
--
thanks much,
Tom Rodman
1st for for error on Monday:
--v-v--C-U-T---H-E-R-E-v-v--
16:09:13 Mon Mar 27 2j tty0 6480 /adm/config/etc
OurSrvr063 staffuser1 make domain local clean4main passwd group clean_local
if ! user_list_external=/adm/db/bcm_users/all_users
/adm/bin/app/s/mkpasswd_4domain_subset passwd.a
then \
echo looks like were not in a domain, not making passwd.autogen.domain 2
;\
/adm/config/etc/passwd.autogen.domain ;\
fi
/adm/config/bp/bash.bp.shinc: fork: Resource temporarily unavailable
--v-v--C-U-T---H-E-R-E-v-v--
Here's the slightly adjusted heap setting on the server:
bash-3.00$ ccs=/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet
bash-3.00$ key=$ccs/Control/Session Manager/SubSystems/Windows
bash-3.00$ perl -lne 'print $1 if m{ (Shar.*?) }' $key
SharedSection=1536,3584,768
snippets of subsequent fork or heap errors from Monday tests:
--v-v--C-U-T---H-E-R-E-v-v--
16:20:32 Mon Mar 27 2j tty0 6480 /etc
OurSrvr063 staffuser1 cd $cf/etc;make domain local clean4main passwd group
clean_local
if ! user_list_external=/adm/db/bcm_users/all_users
/adm/bin/app/s/mkpasswd_4domain_subset passwd.autogen.domain ;\
then \
echo looks like were not in a domain, not making passwd.autogen.domain 2
;\
/adm/config/etc/passwd.autogen.domain ;\
fi
/adm/bin/sys/s/bash_rXF_: fork: Resource temporarily unavailable
5 [main] ? (6484) child_copy: cygheap read copy failed,
0x6115B900..0x611661F4, done 0, windows pid 2291660, Win32 error 5
--snip
PW_AG_DOMAIN=/adm/config/etc/passwd.autogen.domain \
PW_PATCH_DOMAIN=/adm/config/etc/passwd.patch.domain \
PW_PATCH_DOMAIN_LOCALHOST=/etc/passwd.patch.domain.localhost \
/adm/bin/app/s/passwd_mk_passwd.cust.domain /etc/passwd.cust.domain
make: vfork: Resource temporarily unavailable
--snip
16:21:04 Mon Mar 27 2j tty0 6480 /adm/config/etc
OurSrvr063 staffuser1 cd $cf/etc;make domain local clean4main passwd group
clean_local
if ! user_list_external=/adm/db/bcm_users/all_users
/adm/bin/app/s/mkpasswd_4domain_subset passwd.a
utogen.domain ;\
then \
echo looks like were not in a domain, not making passwd.autogen.domain 2
;\
/adm/config/etc/passwd.autogen.domain ;\
fi
/adm/bin/sys/s/bash_rXF_: fork: Resource temporarily unavailable
5 [main] ? (6484) child_copy: cygheap read copy failed,
0x6115B900..0x611661AC, done 0, window
s pid 2291660, Win32 error 5
xargs: error waiting for child process: No child processes
make: *** Deleting file `passwd.autogen.domain'
--snip
17:18:12 Mon Mar 27 0j tty1 1372 ~
OurSrvr063 staffuser1 head /tmp/r7867
mkpasswd -d -u adm_ds || echo failed for [adm_ds] 2
mkpasswd -d -u adm_ndb || echo failed for [adm_ndb] 2
mkpasswd -d -u adm_tsr || echo failed for [adm_tsr] 2
mkpasswd -d -u staffuser2 || echo failed for [staffuser2] 2
mkpasswd -d -u calbrec || echo failed for [calbrec] 2
mkpasswd -d -u camundc || echo failed for [camundc] 2
mkpasswd -d -u carmstl || echo failed for [carmstl] 2
mkpasswd -d -u carshej || echo failed for [carshej] 2
mkpasswd -d -u cartiof || echo failed for [cartiof] 2
mkpasswd -d -u casmusm || echo failed for [casmusm] 2
17:18:14 Mon Mar 27 0j tty1 1372 ~
OurSrvr063 staffuser1 bash -c /tmp/r7867 /dev/null
/tmp/r7867: fork: Resource temporarily unavailable
17:18:23 Mon Mar 27 0j tty1 1372 ~
OurSrvr063 staffuser16 [main] ? (6484) child_copy: cygheap read copy
failed, 0x6115B900..0x61
162524, done 0, windows pid 2291660, Win32 error 5
17:18:58 Mon Mar 27 0j tty1 1372 ~
OurSrvr063 staffuser1 bash -c /tmp/r7867 /dev/null
/tmp
Re: Some new data regarding fork: resource temporarily unavailable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to David Arnstein on 11/6/2005 11:34 AM: I left my machine running all night. The count of handles for System rose to 200,000+, so perhaps this statistic is not relevant. I'll keep looking. Do you have some other program installed that might be keeping these handles alive? (some antivirus programs have been known to cause leaks) - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDb1rC84KuGfSFAYARAgo5AJ9FXcFDFQnRcbk4/LcGMC/Xj3uSDACeMHN9 QIKxUCh5tC/I3im78JR3nFQ= =x3IM -END PGP SIGNATURE- -- 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/
Re: Some new data regarding fork: resource temporarily unavailable
Eric Blake [EMAIL PROTECTED] wrote: According to David Arnstein on 11/6/2005 11:34 AM: I left my machine running all night. The count of handles for System rose to 200,000+, so perhaps this statistic is not relevant. I'll keep looking. Do you have some other program installed that might be keeping these handles alive? (some antivirus programs have been known to cause leaks) I had similar problems with the firewall Agnitum Outpost. If it can help. -- Luc Hermitte -- 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/
Re: Some new data regarding fork: resource temporarily unavailable
David Arnstein wrote: Synopsis: the fork: resource temporarily unavailable problem may be caused by a large number of obsolete process handles. Attached to this e-mail: 1. cygcheck.out: the output from cygcheck -s -v -r 2. tempor.sh: A bash shell script that causes the fork: resource temporarily unavailable problem on my computer. This script searches for identical files by brute force: it launches cmp.exe many times. First, I ran the standard Windows Task Manager with a non-standard column shown: handle count. I noticed something disturbing immediately. There is a process (pseudo process?) named System. What I see on my computer is that for this process, the handle count rises slowly but continuously. This occurs when my computer is almost idle (I have several daemon type processes running, so the machine is never completely idle). If I launch any program, the handle count jumps up. After terminating the program, the handle count does NOT reduce. First of all, on this Win2k SP4 I don't see that behavior. Even when I start several normal Windows programs that value doesn't increase. (It's at 132 here.) Next, I launched Process Explorer which is distributed from http://www.sysinternals.com. This program allows me to examine the handles owned by the System process. What I found is that most of the handles are Process handles. These handles have names of the form Non-existent Process () where is a three to five digit number. I don't have them installed. Finally, I ran the attached shell script tempor.sh. Specifically, I opened a Cygwin command window and, at the bash shell prompt, I typed cd C:/Windows/System32 tempor.sh * This caused tempor.sh to process 2,302 files. This in turn caused tempor.sh to launch cmp.exe more than 2.5 million times. [EMAIL PROTECTED] /cygdrive/c/WINNT/system32 $ ~/tempor.sh * Will process 1858 files... When tempor.sh started, the number of handles owned by the System process was less than 10,000. While tempor.sh was running, I watched the status of the System process in the Windows Task Manager. As expected, I saw the handles count for this process rise continuously and rather quickly: very roughly, 30 units per second. My computer's CPU was 50% to 75% busy at the time. No, no change in the handles value here. Constantly at 132. After many minutes, tempor.sh halted itself with the by-now familiar message fork: resource temporarily unavailable. The number of handles owned by the System process was about 86,000. It appears that Windows itself has a problem clearing out old Process handles from some operating system table. It looks like a problem not specific to Cygwin at all. I admit that the evidence I present is not conclusive. Nevertheless, the fact that there is a boundlessly increasing allocation of a resource (process handles) looks suspiciously like breakage to me. Would someone please suggest a forum (or book) where I can pursue this further. I would like to try to clear out the old handles, the ones with names like Non-existent Process () as referenced in Process Explorer. I usually hate the WFM messages, but I thought I mention it anyway ;) Thank you for any suggestions! Try a current snapshot. That propably won't help for your problem but who knows? Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
Re: Some new data regarding fork: resource temporarily unavailable
On Sun, Nov 06, 2005 at 10:44:37AM -0500, Volker Quetschke wrote: First of all, on this Win2k SP4 I don't see that behavior. Even when I start several normal Windows programs that value doesn't increase. (It's at 132 here.) Thank you for this data Mr. Quetschke. I will test two other machines over the next few days and see if a pattern emerges. I left my machine running all night. The count of handles for System rose to 200,000+, so perhaps this statistic is not relevant. I'll keep looking. -- 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/
Some new data regarding fork: resource temporarily unavailable
Synopsis: the fork: resource temporarily unavailable problem may be caused by a large number of obsolete process handles. Attached to this e-mail: 1. cygcheck.out: the output from cygcheck -s -v -r 2. tempor.sh: A bash shell script that causes the fork: resource temporarily unavailable problem on my computer. This script searches for identical files by brute force: it launches cmp.exe many times. First, I ran the standard Windows Task Manager with a non-standard column shown: handle count. I noticed something disturbing immediately. There is a process (pseudo process?) named System. What I see on my computer is that for this process, the handle count rises slowly but continuously. This occurs when my computer is almost idle (I have several daemon type processes running, so the machine is never completely idle). If I launch any program, the handle count jumps up. After terminating the program, the handle count does NOT reduce. Next, I launched Process Explorer which is distributed from http://www.sysinternals.com. This program allows me to examine the handles owned by the System process. What I found is that most of the handles are Process handles. These handles have names of the form Non-existent Process () where is a three to five digit number. Finally, I ran the attached shell script tempor.sh. Specifically, I opened a Cygwin command window and, at the bash shell prompt, I typed cd C:/Windows/System32 tempor.sh * This caused tempor.sh to process 2,302 files. This in turn caused tempor.sh to launch cmp.exe more than 2.5 million times. When tempor.sh started, the number of handles owned by the System process was less than 10,000. While tempor.sh was running, I watched the status of the System process in the Windows Task Manager. As expected, I saw the handles count for this process rise continuously and rather quickly: very roughly, 30 units per second. My computer's CPU was 50% to 75% busy at the time. After many minutes, tempor.sh halted itself with the by-now familiar message fork: resource temporarily unavailable. The number of handles owned by the System process was about 86,000. It appears that Windows itself has a problem clearing out old Process handles from some operating system table. It looks like a problem not specific to Cygwin at all. I admit that the evidence I present is not conclusive. Nevertheless, the fact that there is a boundlessly increasing allocation of a resource (process handles) looks suspiciously like breakage to me. Would someone please suggest a forum (or book) where I can pursue this further. I would like to try to clear out the old handles, the ones with names like Non-existent Process () as referenced in Process Explorer. Thank you for any suggestions! Cygwin Configuration Diagnostics Current System Time: Sat Nov 05 21:13:50 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: E:\cygwin\usr\local\bin E:\cygwin\bin E:\cygwin\bin E:\cygwin\usr\X11R6\bin d:\Bin d:\Bin32 c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem d:\win32app\sysinternals .\ Output from E:\cygwin\bin\id.exe (nontsec) UID: 1003(David) GID: 513(None) 0(root) 513(None)544(Administrators) 545(Users) 1005(Debugger Users) Output from E:\cygwin\bin\id.exe (ntsec) UID: 1003(David) GID: 513(None) 0(root) 513(None)544(Administrators) 545(Users) 1005(Debugger Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = `David' PWD = `/cygdrive/d/Users/David' CYGWIN = `server ntea ntsec smbntsec' HOME = `/cygdrive/d/Users/David' MAKE_MODE = `unix' HOMEPATH = `\Users\David' MANPATH = `/usr/man:/usr/share/man:/usr/ssl/man:/usr/X11R6/man:/usr/local/man' APPDATA = `C:\Documents and Settings\David\Application Data' VS71COMNTOOLS = `C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' SHELL = `/bin/bash' TERM = `cygwin' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' WINDIR = `C:\WINDOWS' OLDPWD = `/usr/bin' USERDOMAIN = `OWL' OS = `Windows_NT' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' TEMP = `/cygdrive/c/Temp' COMMONPROGRAMFILES = `C:\Program Files\Common Files' USERNAME = `David' PAGER = `most' PROCESSOR_LEVEL = `15' FP_NO_HOST_CHECK = `NO' SYSTEMDRIVE = `C:' USERPROFILE = `C:\Documents and Settings\David' DZK20DIRECTORY = `D:\Users\David\DezkTop' PS1 = `\h \! ' LOGONSERVER = `\\OWL' PROCESSOR_ARCHITECTURE = `x86' INIT_COMPLETE = `true' MANPAGER = `most -s' SHLVL = `1' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = `D:' !D: = `D:\Users\David' PROMPT = `$P$G' COMSPEC = `C:\WINDOWS\system32\cmd.exe' LESS = `-i -e -q' TMP = `/cygdrive/c/Temp' SYSTEMROOT = `C:\WINDOWS' PROCESSOR_REVISION = `0209' !E: = `E:\cygwin\bin' PROGRAMFILES = `C:\Program Files' NUMBER_OF_PROCESSORS = `2' SESSIONNAME = `Console
fork: Resource Temporarily Unavailable (Was Re: Hang with 1.5.18, 1.5.19 snapshot 20051029)
On Wed, 2 Nov 2005, Peter Rehley wrote: [snip] One really odd thing that I did notice on my windows 2000 machines was that when I do a 'ps -ef' many times in a row quickly, the test_configure script that I'm using dies...it either segfaults or I get fork: Resource Temporarily unavailable. I've been recently plagued with a resource temporarily unavailable (a.k.a. EBUSY) fork problem (on WinXP), with 1.5.18, snapshots, and self-build DLLs. I don't know if it's related to what you're seeing. The problem doesn't seem to be reproducible under gdb, but can be reproduced under strace for long-running scripts. I hereby repeat my plea to Cygwin developers for debugging suggestions -- what information would be useful to put into the strace to help (me) track down the source of this problem? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- 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/
Re: solution to cygwin error: Win32 error 487 bash: fork: Resource temporarily unavailable
On 9/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Tero, Finally I got a solution which it works: rebaseall: only ash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash. Hope it could help others to solve the same problem. This was a close one with my fork: Resource temporarily unavailable problem. The compiling of gcc 4.0.1 ran for a much longer time than ever before it crashed. This time it crashed in a new manner: e:\cygwin\bin\sh.exe (2976): *** CreateThread failed for sig - 0x00x0, Win32 e rror 1450 Cheers /pspblizz -- 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/
solution to cygwin error: Win32 error 487 bash: fork: Resource temporarily unavailable
Hi, Tero, I saw your post on the web. I have the same problem for the past two days. Error is as follows: After installing cygwin on Window2000, I have following error after opening cygwin: 1033 [main] bash 2164 fork_copy: linked dll data/bss pass 0 failed, 0x66D000. .0x66D020, done 0, windows pid 1216, Win32 error 487 bash: fork: Resource temporarily unavailable I tried many solutions with no help including: 1) make sure cygwin1.dll has only one copy on the machine. 2) install different versions, different selections 3) rebaseall in the bash. (bash is totally useless except for few commands). Finally I got a solution which it works: rebaseall: only ash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash. Hope it could help others to solve the same problem. Best wishes, --john -- 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/
Re: [OT] Re: fork: Resource temporarily unavailable
Jason Pyeron wrote: I recently upgraded to XP on my laptop from 2000. It seems I can run only about a hundred processes instead of 200-300. Why is the limit so low? Is it adjustable? support and msdn don't seem to say. I can run about 300 processes on my XP SP2 laptop no problem. $ ps -aW|wc -l 285 But: $ ps|wc -l 131 Krzysztof Duleba -- 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/
Re: fork: Resource temporarily unavailable
On Thu, Aug 18, 2005 at 12:01:33AM -0700, David Arnstein wrote: Frequently (but not always) I will launch a Cygwin command window running bash; the new command window prints a message from bash: -- 10 [main] bash 1880 pinfo::wait: Couldn't create pipe tracker for pid 3768, Win32 error 231 bash: fork: Resource temporarily unavailable -- error 231 is ERROR_PIPE_BUSY -- that's a very strange error to be coming from the simple creation of an annonymous pipe. I've created a new snapshot which may work around this problem by trying again when this error is presented. Could you give it a try? http://cygwin.com/snapshots/ cgf -- 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/
Re: fork: Resource temporarily unavailable
On Fri, Aug 19, 2005 at 11:13:51AM -0400, Christopher Faylor wrote: I've created a new snapshot which may work around this problem by trying again when this error is presented. Could you give it a try? Thank you Mr. Faylor. I have installed the cygwin1.dll dated August 19. If I see any relevant messages from Cygwin software, I will post to this mail list. The problem I have is intermittent, so all I can do is (stress) test the DLL from now to eternity. -- 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/
fork: Resource temporarily unavailable
Frequently (but not always) I will launch a Cygwin command window running bash; the new command window prints a message from bash: -- 10 [main] bash 1880 pinfo::wait: Couldn't create pipe tracker for pid 3768, Win32 error 231 bash: fork: Resource temporarily unavailable -- The bash shell in the command window is unusable. Commands typed into the shell return immediately, but have no effect. Sometimes, a Cygwin/bash command window will launch properly, but then the above error message appears in the middle of a lengthy command, such as catman -w. I found a mailing list article that claimed that this problem could be solved by running rebaseall. I did kill all Cygwin processes and services, and ran rebaseall from an ash shell. This did not solve my problem. I have attached the output of cygcheck -s -v -r. Thanks for any suggestions. Cygwin Configuration Diagnostics Current System Time: Wed Aug 17 23:51:21 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: E:\cygwin\usr\local\bin E:\cygwin\bin E:\cygwin\bin E:\cygwin\usr\X11R6\bin d:\Bin d:\Bin32 c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem d:\win32app\sysinternals .\ Output from E:\cygwin\bin\id.exe (nontsec) UID: 1003(David) GID: 513(None) 0(root) 513(None)544(Administrators) 545(Users) 1005(Debugger Users) Output from E:\cygwin\bin\id.exe (ntsec) UID: 1003(David) GID: 513(None) 0(root) 513(None)544(Administrators) 545(Users) 1005(Debugger Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = `David' PWD = `/cygdrive/d/Users/David' CYGWIN = `server ntea ntsec smbntsec' HOME = `/cygdrive/d/Users/David' MAKE_MODE = `unix' HOMEPATH = `\Users\David' MANPATH = `/usr/man:/usr/share/man:/usr/ssl/man:/usr/X11R6/man:/usr/local/man' APPDATA = `C:\Documents and Settings\David\Application Data' VS71COMNTOOLS = `C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' SHELL = `/bin/bash' TERM = `cygwin' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' WINDIR = `C:\WINDOWS' OLDPWD = `/usr/bin' USERDOMAIN = `OWL' OS = `Windows_NT' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' TEMP = `/cygdrive/c/Temp' COMMONPROGRAMFILES = `C:\Program Files\Common Files' USERNAME = `David' PROCESSOR_LEVEL = `15' FP_NO_HOST_CHECK = `NO' SYSTEMDRIVE = `C:' USERPROFILE = `C:\Documents and Settings\David' DZK20DIRECTORY = `D:\Users\David\DezkTop' PS1 = `\h \! ' LOGONSERVER = `\\OWL' PROCESSOR_ARCHITECTURE = `x86' INIT_COMPLETE = `true' SHLVL = `1' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = `D:' !D: = `D:\Users\David' PROMPT = `$P$G' COMSPEC = `C:\WINDOWS\system32\cmd.exe' LESS = `-i -e -q' TMP = `/cygdrive/c/Temp' SYSTEMROOT = `C:\WINDOWS' PROCESSOR_REVISION = `0209' !E: = `E:\cygwin\bin' PROGRAMFILES = `C:\Program Files' NUMBER_OF_PROCESSORS = `2' SESSIONNAME = `Console' COMPUTERNAME = `OWL' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `E:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `E:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `E:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 10001Mb 50% CP CS UN PA FC MXT2 1 d: hd NTFS 14001Mb 57% CP CS UN PA FC MXT2 2 e: hd NTFS 18002Mb 39% CP CS UN PA FC MXT2 3 f: hd NTFS 34334Mb 39% CP CS UN PA FC WDC2 4 g: hd NTFS 57207Mb 59% CP CS UN PA FC WDC7 1 h: cd CDFS 434Mb 100%CS UN AHD4 i: cd CDFS49Mb 100%CS UN 020719_1112 j: cd CDFS 3290Mb 100%CS L05AXLRD1 k: cd CDFS 494Mb 100%CS GEO12NA l: cd CDFS 1922Mb 100%CS UN QTR40ENUD1 m: cd CDFS 1481Mb 100%CS UN VSENARD1 n: cd CDFS 112Mb 100%CS WINRESKIT o: fd N/AN/A p: fd N/AN/A q: fd N/AN
Re: fork: Resource temporarily unavailable
On Thu, 18 Aug 2005, David Arnstein wrote: Frequently (but not always) I will launch a Cygwin command window running bash; the new command window prints a message from bash: -- 10 [main] bash 1880 pinfo::wait: Couldn't create pipe tracker for pid 3768, Win32 error 231 bash: fork: Resource temporarily unavailable -- The bash shell in the command window is unusable. Commands typed into the shell return immediately, but have no effect. Sometimes, a Cygwin/bash command window will launch properly, but then the above error message appears in the middle of a lengthy command, such as catman -w. I found a mailing list article that claimed that this problem could be solved by running rebaseall. I did kill all Cygwin processes and services, and ran rebaseall from an ash shell. This did not solve my problem. I have attached the output of cygcheck -s -v -r. Thanks for any suggestions. I have 3 machines doing the same thing. 2 use cygwin 1 does not. This problem started to manifest itself in the last month or so. They are all XP sp2. I was able to reproduce this on my wifes computer while using netflix, and IE shift click opened about 80 IEs, then no processes would launch until I closed one first. I am looking to comup with a better testcase than open lots of stuff until it breaks. google has not helped. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner Sr. Manager 7 West 24th Street #100 - - +1 (443) 921-0381 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. -- 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/
Re: fork: Resource temporarily unavailable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to David Arnstein on 8/18/2005 1:01 AM: Frequently (but not always) I will launch a Cygwin command window running bash; the new command window prints a message from bash: -- 10 [main] bash 1880 pinfo::wait: Couldn't create pipe tracker for pid 3768, Win32 error 231 bash: fork: Resource temporarily unavailable -- This is not a bug in bash, but a limitation in the number of running processes under Windows. When cygwin cannot create a new process during a fork(), you will get this behavior. Some people have reported success turning off (or swapping) antivirus programs, or other tricks to reduce the number of running processes on their system. Other than that, I don't have any further ideas that might help you. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin bash maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDBVBE84KuGfSFAYARAimxAKCGlGvdmGm8SWan4tngHRyvUXXjcACfa2VS dOzUefpeToh5BJCdlfPdoDk= =KnD2 -END PGP SIGNATURE- -- 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/
[OT] Re: fork: Resource temporarily unavailable
On Thu, 18 Aug 2005, Eric Blake wrote: According to David Arnstein on 8/18/2005 1:01 AM: Frequently (but not always) I will launch a Cygwin command window running bash; the new command window prints a message from bash: -- 10 [main] bash 1880 pinfo::wait: Couldn't create pipe tracker for pid 3768, Win32 error 231 bash: fork: Resource temporarily unavailable -- This is not a bug in bash, but a limitation in the number of running processes under Windows. When cygwin cannot create a new process during a fork(), you will get this behavior. Some people have reported success turning off (or swapping) antivirus programs, or other tricks to reduce the number of running processes on their system. Other than that, I don't have any further ideas that might help you. I recently upgraded to XP on my laptop from 2000. It seems I can run only about a hundred processes instead of 200-300. Why is the limit so low? Is it adjustable? support and msdn don't seem to say. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner Sr. Manager 7 West 24th Street #100 - - +1 (443) 921-0381 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. -- 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/
Fork: Resource temporarily unavailable when trying to run lots of processes
Hi there, Does anyone know of a quick way to increase the number of processes that can be run in the background? I need to have a large number of copies of a small utility listening at the same time and with nothing else open I can only achieve 62 copies before I get the message below (gentask is the name of the script): ./gentask: fork: Resource temporarily unavailable and everything stops. Some snippets of information from Cygcheck are attached. Thank you in advance. Roberto. == Dell Latitude C810 PIII 1.13GHz 2512MB RAM 30GBHD CYGWIN_NT-5.0 lu 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown Cygwin Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Dec 31 15:10:54 2003 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Cygwin DLL version info: DLL version: 1.5.5 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 94 Shared data: 3 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Sat Sep 20 16:31:15 EDT 2003 CVS tag: cr-0x9b Shared id: cygwin1S3 __ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 -- 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/
RE: Cannot fork: Resource temporarily unavailable
I am trying to rebuild the Cygwin tools under W98 and keep getting this
error message when running make:
Cannot fork: Resource temporarily unavailable.
Despite rebooting the machine and ensuring that sufficient swap space is
available this continues to recur.
This is the extract from the make.log
fi
make[2]: Leaving directory `/obj/i686-pc-cygwin/libiberty'
make[1]: Leaving directory `/obj/i686-pc-cygwin/libiberty'
Configuring in i686-pc-cygwin/winsup
loading cache ../config.cache
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking build system type... i686-pc-cygwin
checking for gcc... (cached) gcc -L/obj/i686-pc-cygwin/winsup
-L/obj/i686-pc-cygwin/winsup/cygwin
-L/obj/i686-pc-cygwin/winsup/w32api/lib
-isystem /src/winsup/include -isystem /src/winsup/cygwin/include -isystem
/src/winsup/w32api/include -isystem /src/newlib/libc/sys/cygwin -isystem
/src/newlib/libc/sys/cygwin32 -B/obj/i686-pc-cygwin/newlib/ -isystem
/obj/i686-pc-cygwin/newlib/targ-include -isystem /src/newlib/libc/include
checking whether we are using GNU C... (cached) yes
checking whether gcc -L/obj/i686-pc-cygwin/winsup
-L/obj/i686-pc-cygwin/winsup/cygwin
-L/obj/i686-pc-cygwin/winsup/w32api/lib
-isystem /src/winsup/include -isystem /src/winsup/cygwin/include -isystem
/src/winsup/w32api/include -isystem /src/newlib/libc/sys/cygwin -isystem
/src/newlib/libc/sys/cygwin32 -B/obj/i686-pc-cygwin/newlib/ -isystem
/obj/i686-pc-cygwin/newlib/targ-include -isystem /src/newlib/libc/include
accepts -g... (cached) yes
checking for g++... c++ -L/obj/i686-pc-cygwin/winsup
-L/obj/i686-pc-cygwin/winsup/cygwin
-L/obj/i686-pc-cygwin/winsup/w32api/lib
-isystem /src/winsup/include -isystem /src/winsup/cygwin/include -isystem
/src/winsup/w32api/include -isystem /src/newlib/libc/sys/cygwin -isystem
/src/newlib/libc/sys/cygwin32 -B/obj/i686-pc-cygwin/newlib/ -isystem
/obj/i686-pc-cygwin/newlib/targ-include -isystem /src/newlib/libc/include
checking whether make sets ${MAKE}... (cached) yes
updating cache ../config.cache
creating ./config.status
/src/winsup/configure: Cannot fork: Resource temporarily unavailable
/src/winsup/configure: Cannot fork: Resource temporarily unavailable
make: *** [configure-target-winsup] Error 1
Can anyone offer me any advice.
Thanks.
This may happen because you have some other process which is opening the
process handle for new processes (such as a virus checker) but not closing
it. Try closing all running programs and then compiling again. Remember that
on Windows 98 not all processes show up in task manager so you will need
some other kind of process explorer to close them or remove them from the
RunServices registry key. Please report back and tell us if this solves the
problem or not.
Chris
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Cannot fork: Resource temporarily unavailable
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Chris January Cc: [EMAIL PROTECTED] I am trying to rebuild the Cygwin tools under W98 and keep getting this error message when running make: -- 8 -- Can anyone offer me any advice. Thanks. This may happen because you have some other process which is opening the process handle for new processes (such as a virus checker) but not closing it. Try closing all running programs and then compiling again. Remember that on Windows 98 not all processes show up in task manager so you will need some other kind of process explorer to close them or remove them from the RunServices registry key. Please report back and tell us if this solves the problem or not. Chris This might help: Start - Run - msconfig /Hannu E K Nevalainen, Mariefred, Sweden --END OF MESSAGE-- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cannot fork: Resource temporarily unavailable
I am trying to rebuild the Cygwin tools under W98 and keep getting this
error message when running make:
Cannot fork: Resource temporarily unavailable.
Despite rebooting the machine and ensuring that sufficient swap space is
available this continues to recur.
This is the extract from the make.log
fi
make[2]: Leaving directory `/obj/i686-pc-cygwin/libiberty'
make[1]: Leaving directory `/obj/i686-pc-cygwin/libiberty'
Configuring in i686-pc-cygwin/winsup
loading cache ../config.cache
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking build system type... i686-pc-cygwin
checking for gcc... (cached) gcc -L/obj/i686-pc-cygwin/winsup
-L/obj/i686-pc-cygwin/winsup/cygwin -L/obj/i686-pc-cygwin/winsup/w32api/lib
-isystem /src/winsup/include -isystem /src/winsup/cygwin/include -isystem
/src/winsup/w32api/include -isystem /src/newlib/libc/sys/cygwin -isystem
/src/newlib/libc/sys/cygwin32 -B/obj/i686-pc-cygwin/newlib/ -isystem
/obj/i686-pc-cygwin/newlib/targ-include -isystem /src/newlib/libc/include
checking whether we are using GNU C... (cached) yes
checking whether gcc -L/obj/i686-pc-cygwin/winsup
-L/obj/i686-pc-cygwin/winsup/cygwin -L/obj/i686-pc-cygwin/winsup/w32api/lib
-isystem /src/winsup/include -isystem /src/winsup/cygwin/include -isystem
/src/winsup/w32api/include -isystem /src/newlib/libc/sys/cygwin -isystem
/src/newlib/libc/sys/cygwin32 -B/obj/i686-pc-cygwin/newlib/ -isystem
/obj/i686-pc-cygwin/newlib/targ-include -isystem /src/newlib/libc/include
accepts -g... (cached) yes
checking for g++... c++ -L/obj/i686-pc-cygwin/winsup
-L/obj/i686-pc-cygwin/winsup/cygwin -L/obj/i686-pc-cygwin/winsup/w32api/lib
-isystem /src/winsup/include -isystem /src/winsup/cygwin/include -isystem
/src/winsup/w32api/include -isystem /src/newlib/libc/sys/cygwin -isystem
/src/newlib/libc/sys/cygwin32 -B/obj/i686-pc-cygwin/newlib/ -isystem
/obj/i686-pc-cygwin/newlib/targ-include -isystem /src/newlib/libc/include
checking whether make sets ${MAKE}... (cached) yes
updating cache ../config.cache
creating ./config.status
/src/winsup/configure: Cannot fork: Resource temporarily unavailable
/src/winsup/configure: Cannot fork: Resource temporarily unavailable
make: *** [configure-target-winsup] Error 1
Can anyone offer me any advice.
Thanks.
Best Regards
Jim
___
BT Computing Partners
Intelligent Systems Management
__
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Cannot fork: Resource temporarily unavailable
Funny you should mention that... often noted but not yet answered... http://cygwin.com/ml/cygwin/2003-03/msg01506.html http://cygwin.com/ml/cygwin/2003-03/msg01350.html http://cygwin.com/ml/cygwin/2003-03/msg01393.html http://sources.redhat.com/ml/cygwin/2002-02/msg01188.html http://sources.redhat.com/ml/cygwin/2002-07/msg01894.html http://sources.redhat.com/ml/cygwin/2002-05/msg01333.html http://sources.redhat.com/ml/cygwin/2002-02/msg01361.html http://sources.redhat.com/ml/cygwin/2002-02/msg00304.html http://sources.redhat.com/ml/cygwin/2001-07/msg00382.html http://sources.redhat.com/ml/cygwin/2001-07/msg00193.html __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
