On Tue, Feb 07, 2012 at 07:00:25AM -0800, Scott M. Ballew wrote: >> >> I've got a Windows XP SP3 (32-bit) system that I just upgraded from Cygwin >> 1.5 to Cygwin 1.7 as a clean install (deinstalled all old Cygwin, scrubbed >> the registry, cleared environment variables, etc.) Mostly, it seems to work, >> but I've got a shell script that runs several rsync's for me that does not >> work right. Some of the rsync's run correctly, and others give me: >> >> hostname1: updating host hostname1 >> 3 [main] rsync 3112 child_info_fork::abort: address space needed by >> 'cygiconv-2.dll' (0x674C0000) is already occupied >> 3 [main] rsync 3112 child_info_fork::abort: address space needed by >> 'cygiconv-2.dll' (0x674C0000) is already occupied >> rsync: fork: Resource temporarily unavailable (11) >> rsync error: error in IPC code (code 14) at >> /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/pipe.c(63) [sender=3.0.9] >> hostname1: updating of hostname1 finished I've the same system same problem. I usually do a fresh install every 4 or 6 months. I cannot tell that cygiconv-2.dll is the only one that triggers this, but recently (15 days) yes (in older times, cyggcc_s-1.dll was also often in the message). But the process in cause varies: sh, tcsh, gcc-4 etc. rsync i don't think so. >> >> I've tried "rebaseall", and that only moved the address reported for >> cygiconv-2.dll. Even tried "rebaseall -b 0x68000000" and "rebaseall -b >> 0x78000000". Again, the only effect was to change the address where >> cygiconv-2.dll wants to load. Me too. Exactly the same.
I've also instrumented cygwin1.dll as suggested recently to Heiko Elger in http://cygwin.com/ml/cygwin/2012-02/msg00092.html (note that he was also talking cygiconv-2.dll) and i installed Sleep(3600000L) (1 hour) to have plenty of time. Observations are: - now that i expect fork failures, they seem to appear less often... - the launching of my X session (xinit) is blocked by a 2nd XWin.exe that presumably now waits 1hour to die, if i kill it directly from TaskManager, all is fine, but this is another subject... - the /proc/<pid>/maps of the processes involved in the fork failure look normal: ... 61262000-61470000 rw-p 00262000 C095:C492 13792273859134500 /usr/bin/cygwin1.dll 674C0000-674C1000 r--p 00000000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 674C1000-674D8000 r-xp 00001000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 674D8000-675B8000 rw-p 00018000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 675B8000-675B9000 r--p 000F8000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 675B9000-675BB000 rw-p 000F9000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 675BB000-675BC000 r--p 000FB000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 6AFC0000-6AFC1000 r--p 00000000 C095:C492 1407374884189126 /usr/bin/cygreadline7.dll ... Now looking into dll_init.cc, i'm probably going to try the following: if VirtualAlloc (line 429, just before 'already occupied') fails, try it once more after waiting, say 100ms. Any comments? Regards, Denis Excoffier. -- 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
