* cygwin-1.7.10-1 fork - address space needed by ... already in use @ 2012-02-07 15:00 Scott M. Ballew 2012-02-07 15:44 ` Denis Excoffier 0 siblings, 1 reply; 51+ messages in thread From: Scott M. Ballew @ 2012-02-07 15:00 UTC (permalink / raw) To: cygwin 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 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. I've tried using ProcessExplorer from SysInternals to see what DLLs are loaded where, but I haven't been able to spot the one that might be colliding. Suggestions for how to continue digging into this? I've tried to read the forum posts that seem related and any Google hits that seemed related, but to no avail. Thanks, Scott M. Ballew Purdue University -- View this message in context: http://old.nabble.com/cygwin-1.7.10-1-fork---address-space-needed-by-...-already-in-use-tp33279157p33279157.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-07 15:00 cygwin-1.7.10-1 fork - address space needed by ... already in use Scott M. Ballew @ 2012-02-07 15:44 ` Denis Excoffier 2012-02-07 16:15 ` Corinna Vinschen 0 siblings, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-02-07 15:44 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-07 15:44 ` Denis Excoffier @ 2012-02-07 16:15 ` Corinna Vinschen 2012-02-07 16:47 ` Ryan Johnson 0 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-02-07 16:15 UTC (permalink / raw) To: cygwin On Feb 7 16:43, Denis Excoffier wrote: > I've also instrumented cygwin1.dll as suggested recently to Heiko Elger > in http://cygwin.com/ml/cygwin/2012-02/msg00092.html > [...] > - 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 > ... If this is the map of the forked child, then it's not exactly normal. Consider that dll_list::reserve_space tries to reserve the memory which is later supposed to be used for cygiconv-2.dll, but apparently cygiconv-2.dll is already loaded. What your report is missing is a bit more information. We external observes don't know if the error message in reserve_space actually reported the address 0x674C0000, and we also don't know if the parent process has the same layout as the child, or if it's different. The above information alone is not enough to evaluate the situation around cygiconv-2.dll in your scenario. > 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? Don't, it won't help. Assuming my above assumptions are correct (but we need proof), we seem to have a situation like this: - cygiconv-2.dll has been loaded before cygwin1.dll - cygwin1.dll tries to reserve space for later loading of cygiconv-2.dll but cygiconv-2.dll is already where it belongs. - Since rsync is linked against cygiconv-2.dll, I'm wondering why it's in the list of runtime loaded DLLs. And, for the records: - These changes are basically more than 6 months old. It's really frustrating that I never saw this problem even once on one of my test machines. And I still can't. Can anybody paste a command which fails like this into a mail? If possible, one which is reproducible from another machine, like one of mine? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-07 16:15 ` Corinna Vinschen @ 2012-02-07 16:47 ` Ryan Johnson 2012-02-07 22:48 ` Denis Excoffier 0 siblings, 1 reply; 51+ messages in thread From: Ryan Johnson @ 2012-02-07 16:47 UTC (permalink / raw) To: cygwin On 07/02/2012 11:14 AM, Corinna Vinschen wrote: > On Feb 7 16:43, Denis Excoffier wrote: >> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger >> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html >> [...] >> - 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 >> ... > If this is the map of the forked child, then it's not exactly normal. > Consider that dll_list::reserve_space tries to reserve the memory which > is later supposed to be used for cygiconv-2.dll, but apparently > cygiconv-2.dll is already loaded. > > What your report is missing is a bit more information. We external > observes don't know if the error message in reserve_space actually > reported the address 0x674C0000, and we also don't know if the parent > process has the same layout as the child, or if it's different. The > above information alone is not enough to evaluate the situation around > cygiconv-2.dll in your scenario. > >> 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? > Don't, it won't help. Assuming my above assumptions are correct (but we > need proof), we seem to have a situation like this: > > - cygiconv-2.dll has been loaded before cygwin1.dll > > - cygwin1.dll tries to reserve space for later loading of cygiconv-2.dll > but cygiconv-2.dll is already where it belongs. > > - Since rsync is linked against cygiconv-2.dll, I'm wondering > why it's in the list of runtime loaded DLLs. Denis, could you recompile cygwin1.dll to print out the list of dlls, and their types, on fork failure? IIRC, the list is pretty easy to traverse (singly-linked list rooted in a global variable or something similar). That might confirm or rule out Corinna's hypothesis. I also have a hypothesis to suggest: if cygwin1.dll loaded after cygiconv-2.dll (which I've seen happen), but initialized first (which it should, to preserve dependencies) then it's possible for dll_list::reserve_space to trip over a badly-placed cygiconv-2.dll before dll_list::alloc runs for cygiconv and checks its placement. This could be confirmed by comparing parent and child process maps. BTW, what initialization do cyg*.dll do when they run? I have vague memories that they basically just check in with cygwin1.dll and then save their real init for some other function that is only called for non-forkee processes. If they do much of anything else, tho, it would be possible for dynamic dlls depending on static ones to init before their static dependencies. Even if that doesn't cause problems, is it possible that cygiconv isn't on the dll list yet for some reason, causing it to be treated as dynamically loaded? Again, my vague memory is that the dll list comes from the parent process, which would avoid the problem, but I can't remember for sure. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-07 16:47 ` Ryan Johnson @ 2012-02-07 22:48 ` Denis Excoffier 2012-02-08 9:03 ` Corinna Vinschen 2012-02-08 9:08 ` Denis Excoffier 0 siblings, 2 replies; 51+ messages in thread From: Denis Excoffier @ 2012-02-07 22:48 UTC (permalink / raw) To: cygwin On 2012-02-07 17:47, Ryan Johnson wrote: > On 07/02/2012 11:14 AM, Corinna Vinschen wrote: >> On Feb 7 16:43, Denis Excoffier wrote: >>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger >>> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html >>> [...] >>> - 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 >>> ... >> If this is the map of the forked child, then it's not exactly normal. >> Consider that dll_list::reserve_space tries to reserve the memory which >> is later supposed to be used for cygiconv-2.dll, but apparently >> cygiconv-2.dll is already loaded. >> >> What your report is missing is a bit more information. We external >> observes don't know if the error message in reserve_space actually >> reported the address 0x674C0000, and we also don't know if the parent >> process has the same layout as the child, or if it's different. The >> above information alone is not enough to evaluate the situation around >> cygiconv-2.dll in your scenario. >> >>> 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? >> Don't, it won't help. Assuming my above assumptions are correct (but we >> need proof), we seem to have a situation like this: >> >> - cygiconv-2.dll has been loaded before cygwin1.dll >> >> - cygwin1.dll tries to reserve space for later loading of cygiconv-2.dll >> but cygiconv-2.dll is already where it belongs. >> >> - Since rsync is linked against cygiconv-2.dll, I'm wondering >> why it's in the list of runtime loaded DLLs. > Denis, could you recompile cygwin1.dll to print out the list of dlls, and their types, on fork failure? IIRC, the list is pretty easy to traverse (singly-linked list rooted in a global variable or something similar). That might confirm or rule out Corinna's hypothesis. You mean, something like this: void dll_list::reserve_space () { for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ()) #ifdef PRISTINE if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) fabort ("address space needed by '%W' (%p) is already occupied", d->modname, d->handle); #else #define TYPE_SHOW(x) ((x) == DLL_NONE) ? "DLL_NONE" : ((x) == DLL_LINK) ? "DLL_LINK" : ((x) == DLL_LOAD) ? "DLL_LOAD" : ((x) == DLL_ANY) ? "DLL_ANY" : "DLL_(unknown)" if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) { #if 0 for (dll* d_alt = dlls.istart (DLL_ANY); d_alt; d_alt = dlls.inext ()) { system_printf ("address space needed by '%W' (%p with type %d=%s) is perhaps already occupied", d_alt->modname, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type)); }; #else for (dll* d_alt = dlls.start.next; d_alt; d_alt = d_alt.next ()) { system_printf ("address space needed by '%W' (%p with type %d=%s) is perhaps already occupied", d_alt->modname, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type)); }; #endif fabort ("address space needed by '%W' (%p) is already occupied", d->modname, d->handle); }; #endif } By the way, if someone can explain why in dll_init.h we have dll *istart (dll_type t) { hold_type = t; hold = &start; return inext (); } and not dll *istart (dll_type t) { hold_type = t; hold = &start; return hold; } 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-07 22:48 ` Denis Excoffier @ 2012-02-08 9:03 ` Corinna Vinschen 2012-02-08 9:08 ` Denis Excoffier 1 sibling, 0 replies; 51+ messages in thread From: Corinna Vinschen @ 2012-02-08 9:03 UTC (permalink / raw) To: cygwin On Feb 7 23:48, Denis Excoffier wrote: > On 2012-02-07 17:47, Ryan Johnson wrote: > > On 07/02/2012 11:14 AM, Corinna Vinschen wrote: > >> On Feb 7 16:43, Denis Excoffier wrote: > >>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger > >>> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html > >>> [...] > >>> - 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 > >>> ... > >> If this is the map of the forked child, then it's not exactly normal. > >> Consider that dll_list::reserve_space tries to reserve the memory which > >> is later supposed to be used for cygiconv-2.dll, but apparently > >> cygiconv-2.dll is already loaded. > >> > >> What your report is missing is a bit more information. We external > >> observes don't know if the error message in reserve_space actually > >> reported the address 0x674C0000, and we also don't know if the parent > >> process has the same layout as the child, or if it's different. The > >> above information alone is not enough to evaluate the situation around > >> cygiconv-2.dll in your scenario. What about this, Denis? Can you please fgive us this information for a start? > >>> 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? > >> Don't, it won't help. Assuming my above assumptions are correct (but we > >> need proof), we seem to have a situation like this: > >> > >> - cygiconv-2.dll has been loaded before cygwin1.dll > >> > >> - cygwin1.dll tries to reserve space for later loading of cygiconv-2.dll > >> but cygiconv-2.dll is already where it belongs. > >> > >> - Since rsync is linked against cygiconv-2.dll, I'm wondering > >> why it's in the list of runtime loaded DLLs. > > Denis, could you recompile cygwin1.dll to print out the list of dlls, and their types, on fork failure? IIRC, the list is pretty easy to traverse (singly-linked list rooted in a global variable or something similar). That might confirm or rule out Corinna's hypothesis. > You mean, something like this: I removed the #if stuff for better readability: > void > dll_list::reserve_space () > { > for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ()) > #define TYPE_SHOW(x) ((x) == DLL_NONE) ? "DLL_NONE" : ((x) == DLL_LINK) ? "DLL_LINK" : ((x) == DLL_LOAD) ? "DLL_LOAD" : ((x) == DLL_ANY) ? "DLL_ANY" : "DLL_(unknown)" > if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) { > for (dll* d_alt = dlls.start.next; d_alt; d_alt = d_alt.next ()) { > system_printf ("address space needed by '%W' (%p with type %d=%s) is perhaps already occupied", It doesn't matter, but I'd drop the trailing "is perhaps already occupied". The list is just informational anyway. > d_alt->modname, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type)); > }; > fabort ("address space needed by '%W' (%p) is already occupied", > d->modname, d->handle); > }; > } > > > By the way, if someone can explain why in dll_init.h we have > > dll *istart (dll_type t) > { > hold_type = t; > hold = &start; > return inext (); > } > > and not > > dll *istart (dll_type t) > { > hold_type = t; > hold = &start; > return hold; > } It would be wrong. start is only used as an anchor. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-07 22:48 ` Denis Excoffier 2012-02-08 9:03 ` Corinna Vinschen @ 2012-02-08 9:08 ` Denis Excoffier 2012-02-08 9:27 ` Corinna Vinschen 1 sibling, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-02-08 9:08 UTC (permalink / raw) To: cygwin On Tue, Feb 07, 2012 at 11:48:35PM +0100, Denis Excoffier wrote: >> >> On 2012-02-07 17:47, Ryan Johnson wrote: >> > On 07/02/2012 11:14 AM, Corinna Vinschen wrote: >> >> On Feb 7 16:43, Denis Excoffier wrote: >> >>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger >> >>> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html >> >>> [...] >> >>> - 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 >> >>> ... >> >> If this is the map of the forked child, then it's not exactly normal. >> >> Consider that dll_list::reserve_space tries to reserve the memory which >> >> is later supposed to be used for cygiconv-2.dll, but apparently >> >> cygiconv-2.dll is already loaded. >> >> >> >> What your report is missing is a bit more information. We external >> >> observes don't know if the error message in reserve_space actually >> >> reported the address 0x674C0000, and we also don't know if the parent >> >> process has the same layout as the child, or if it's different. The >> >> above information alone is not enough to evaluate the situation around >> >> cygiconv-2.dll in your scenario. >> >> >> >>> 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? >> >> Don't, it won't help. Assuming my above assumptions are correct (but we >> >> need proof), we seem to have a situation like this: >> >> >> >> - cygiconv-2.dll has been loaded before cygwin1.dll >> >> >> >> - cygwin1.dll tries to reserve space for later loading of cygiconv-2.dll >> >> but cygiconv-2.dll is already where it belongs. >> >> >> >> - Since rsync is linked against cygiconv-2.dll, I'm wondering >> >> why it's in the list of runtime loaded DLLs. >> > Denis, could you recompile cygwin1.dll to print out the list of dlls, and their types, on fork failure? IIRC, the list is pretty easy to traverse (singly-linked list rooted in a global variable or something similar). That might confirm or rule out Corinna's hypothesis. >> You mean, something like this: >> >> void >> dll_list::reserve_space () >> { >> for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ()) >> #ifdef PRISTINE >> if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) >> fabort ("address space needed by '%W' (%p) is already occupied", >> d->modname, d->handle); >> #else >> #define TYPE_SHOW(x) ((x) == DLL_NONE) ? "DLL_NONE" : ((x) == DLL_LINK) ? "DLL_LINK" : ((x) == DLL_LOAD) ? "DLL_LOAD" : ((x) == DLL_ANY) ? "DLL_ANY" : "DLL_(unknown)" >> if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) { >> #if 0 >> for (dll* d_alt = dlls.istart (DLL_ANY); d_alt; d_alt = dlls.inext ()) { >> system_printf ("address space needed by '%W' (%p with type %d=%s) is perhaps already occupied", >> d_alt->modname, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type)); >> }; >> #else >> for (dll* d_alt = dlls.start.next; d_alt; d_alt = d_alt.next ()) { >> system_printf ("address space needed by '%W' (%p with type %d=%s) is perhaps already occupied", >> d_alt->modname, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type)); >> }; >> #endif >> fabort ("address space needed by '%W' (%p) is already occupied", >> d->modname, d->handle); >> }; >> #endif >> } >> Yes. Except for "d_alt.next ()" to be replaced by "d_alt->next" of course (if you want to compile...). Result is: 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied 2802 [main] gcc-4 4084 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied 2 [main] gcc 3740 child_info::sync: wait failed, pid 4084, Win32 error 0 1144 [main] gcc 3740 fork: child -1 - forked process died unexpectedly, retry 0, exit code 2279704, errno 11 1006109 [main] gcc-4 1388 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied 1006851 [main] gcc-4 1388 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied 1007394 [main] gcc-4 1388 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied 1007875 [main] gcc-4 1388 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied 1008226 [main] gcc-4 1388 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied 301001997 [main] gcc 3740 child_info::sync: wait failed, pid 1388, Win32 error 0 301004125 [main] gcc 3740 fork: child -1 - forked process died unexpectedly, retry 0, exit code 2279704, errno 11 303018670 [main] gcc-4 324 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied 303019677 [main] gcc-4 324 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied 303020109 [main] gcc-4 324 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied 303020474 [main] gcc-4 324 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied 303020823 [main] gcc-4 324 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied 603005620 [main] gcc 3740 child_info::sync: wait failed, pid 324, Win32 error 0 603009573 [main] gcc 3740 fork: child -1 - forked process died unexpectedly, retry 0, exit code 2279704, errno 11 607020131 [main] gcc-4 492 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied 607021534 [main] gcc-4 492 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied 607021898 [main] gcc-4 492 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied 607022240 [main] gcc-4 492 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied 607022584 [main] gcc-4 492 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied and associated /proc/4084/maps is: 00010000-00011000 rw-p 00000000 0000:0000 0 00020000-00021000 rw-p 00000000 0000:0000 0 00030000-0020B000 ===p 00000000 0000:0000 0 [stack (tid 4052)] 0020B000-0020C000 rw-g 001DB000 0000:0000 0 [stack (tid 4052)] 0020C000-00230000 rw-p 001DC000 0000:0000 0 [stack (tid 4052)] 00230000-00233000 r--s 00000000 0000:0000 0 00240000-00244000 rw-p 00000000 0000:0000 0 00244000-00340000 ===p 00004000 0000:0000 0 00340000-00346000 rw-p 00000000 0000:0000 0 [win heap 0 default grow] 00346000-00350000 ===p 00006000 0000:0000 0 [win heap 0 default grow] 00350000-00353000 rw-s 00000000 0000:0000 0 [win heap 1 grow] 00353000-00360000 ===s 00003000 0000:0000 0 [win heap 1 grow] 00360000-00376000 r--s 00000000 C095:C492 281474976712054 /cygdrive/d/WINDOWS/system32/unicode.nls 00380000-003C1000 r--s 00000000 C095:C492 281474976713091 /cygdrive/d/WINDOWS/system32/locale.nls 003D0000-003D6000 r--s 00000000 C095:C492 281474976713631 /cygdrive/d/WINDOWS/system32/sorttbls.nls 00400000-00401000 r--p 00000000 C095:C492 2814749767676467 /usr/bin/gcc-4.exe 00401000-0041B000 r-xp 00001000 C095:C492 2814749767676467 /usr/bin/gcc-4.exe 0041B000-0043D000 rw-p 0001B000 C095:C492 2814749767676467 /usr/bin/gcc-4.exe 00440000-00481000 r--s 00000000 C095:C492 281474976713630 /cygdrive/d/WINDOWS/system32/sortkey.nls 00490000-0068B000 ===p 00000000 0000:0000 0 [stack (tid 3892)] 0068B000-0068C000 rw-g 001FB000 0000:0000 0 [stack (tid 3892)] 0068C000-00690000 rw-p 001FC000 0000:0000 0 [stack (tid 3892)] 20000000-20060000 rw-p 00000000 0000:0000 0 [heap] 20060000-38000000 ===p 00060000 0000:0000 0 [heap] 60FD0000-60FE0000 rw-s 00000000 0000:0000 0 [procinfo] 60FE0000-60FE9000 rw-s 00000000 0000:0000 0 [cygwin-user-shared] 60FF0000-60FF6000 rw-s 00000000 0000:0000 0 [cygwin-shared] 61000000-61001000 r--p 00000000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61001000-6117B000 r-xp 00001000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6117B000-6117D000 rwxp 0017B000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6117D000-6119D000 rw-p 0017D000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6119D000-611FC000 r--p 0019D000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 611FC000-61231000 rw-p 001FC000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61231000-6123B000 r--p 00231000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6123B000-6123C000 rw-p 0023B000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6123C000-61256000 r--p 0023C000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61256000-61261000 rw-p 00256000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61261000-61262000 r--p 00261000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61262000-61470000 rw-p 00262000 C095:C492 106679016173352090 /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 6F5C0000-6F5C1000 r--p 00000000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C1000-6F5C7000 r-xp 00001000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C7000-6F5C8000 rw-p 00007000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C8000-6F5C9000 r--p 00008000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C9000-6F5CB000 rw-p 00009000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5CB000-6F5CC000 r--p 0000B000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5CC000-6F5CE000 rw-p 0000C000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5CE000-6F5CF000 r--p 0000E000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 7C800000-7C801000 r--p 00000000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C801000-7C885000 r-xp 00001000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C885000-7C88A000 rw-p 00085000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C88A000-7C906000 r--p 0008A000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C910000-7C911000 r--p 00000000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C911000-7C98E000 r-xp 00001000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C98E000-7C993000 rw-p 0007E000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C993000-7C9C9000 r--p 00083000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7F6F0000-7F6F7000 r-xs 00000000 0000:0000 0 7F6F7000-7F7F0000 ===s 00007000 0000:0000 0 7FFB0000-7FFD4000 r--s 00000000 0000:0000 0 7FFDD000-7FFDE000 rw-p 00000000 0000:0000 0 [teb (tid 3892)] 7FFDE000-7FFDF000 rw-p 00000000 0000:0000 0 [teb (tid 4052)] 7FFDF000-7FFE0000 rw-p 00000000 0000:0000 0 [peb] 7FFE0000-7FFE1000 r--p 00000000 0000:0000 0 [shared-user-data] 7FFE1000-7FFF0000 ===p 00001000 0000:0000 0 and /proc/3740/maps is 00010000-00011000 rw-p 00000000 0000:0000 0 00020000-00021000 rw-p 00000000 0000:0000 0 00030000-0020B000 ===p 00000000 0000:0000 0 [stack (tid 2652)] 0020B000-0020C000 rw-g 001DB000 0000:0000 0 [stack (tid 2652)] 0020C000-00230000 rw-p 001DC000 0000:0000 0 [stack (tid 2652)] 00230000-00233000 r--s 00000000 0000:0000 0 00240000-00248000 rw-p 00000000 0000:0000 0 00248000-00340000 ===p 00008000 0000:0000 0 00340000-00346000 rw-p 00000000 0000:0000 0 [win heap 0 default grow] 00346000-00350000 ===p 00006000 0000:0000 0 [win heap 0 default grow] 00350000-00353000 rw-s 00000000 0000:0000 0 [win heap 1 grow] 00353000-00360000 ===s 00003000 0000:0000 0 [win heap 1 grow] 00360000-00376000 r--s 00000000 C095:C492 281474976712054 /cygdrive/d/WINDOWS/system32/unicode.nls 00380000-003C1000 r--s 00000000 C095:C492 281474976713091 /cygdrive/d/WINDOWS/system32/locale.nls 003D0000-003D6000 r--s 00000000 C095:C492 281474976713631 /cygdrive/d/WINDOWS/system32/sorttbls.nls 003E0000-003E1000 rw-s 00000000 0000:0000 0 003F0000-003FE000 rw-s 00000000 0000:0000 0 00400000-00401000 r--p 00000000 C095:C492 2814749767676467 /usr/bin/gcc-4.exe 00401000-0041B000 r-xp 00001000 C095:C492 2814749767676467 /usr/bin/gcc-4.exe 0041B000-0043D000 rw-p 0001B000 C095:C492 2814749767676467 /usr/bin/gcc-4.exe 00440000-00481000 r--s 00000000 C095:C492 281474976713630 /cygdrive/d/WINDOWS/system32/sortkey.nls 00490000-0068B000 ===p 00000000 0000:0000 0 [stack (tid 672)] 0068B000-0068C000 rw-g 001FB000 0000:0000 0 [stack (tid 672)] 0068C000-00690000 rw-p 001FC000 0000:0000 0 [stack (tid 672)] 00690000-00691000 rw-p 00000000 0000:0000 0 20000000-20060000 rw-p 00000000 0000:0000 0 [heap] 20060000-38000000 ===p 00060000 0000:0000 0 [heap] 60FD0000-60FE0000 rw-s 00000000 0000:0000 0 [procinfo] 60FE0000-60FE9000 rw-s 00000000 0000:0000 0 [cygwin-user-shared] 60FF0000-60FF6000 rw-s 00000000 0000:0000 0 [cygwin-shared] 61000000-61001000 r--p 00000000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61001000-6117B000 r-xp 00001000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6117B000-6117D000 rwxp 0017B000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6117D000-6119D000 rw-p 0017D000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6119D000-611FC000 r--p 0019D000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 611FC000-61231000 rw-p 001FC000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61231000-6123B000 r--p 00231000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6123B000-6123C000 rw-p 0023B000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 6123C000-61256000 r--p 0023C000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61256000-61261000 rw-p 00256000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61261000-61262000 r--p 00261000 C095:C492 106679016173352090 /usr/bin/cygwin1.dll 61262000-61470000 rw-p 00262000 C095:C492 106679016173352090 /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 6F5C0000-6F5C1000 r--p 00000000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C1000-6F5C7000 r-xp 00001000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C7000-6F5C8000 rw-p 00007000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C8000-6F5C9000 r--p 00008000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5C9000-6F5CB000 rw-p 00009000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5CB000-6F5CC000 r--p 0000B000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5CC000-6F5CE000 rw-p 0000C000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 6F5CE000-6F5CF000 r--p 0000E000 C095:C492 2814749767737646 /usr/bin/cygintl-8.dll 77DA0000-77DA1000 r--p 00000000 C095:C492 562949953453878 /cygdrive/d/WINDOWS/system32/advapi32.dll 77DA1000-77E16000 r-xp 00001000 C095:C492 562949953453878 /cygdrive/d/WINDOWS/system32/advapi32.dll 77E16000-77E1B000 rw-p 00076000 C095:C492 562949953453878 /cygdrive/d/WINDOWS/system32/advapi32.dll 77E1B000-77E4C000 r--p 0007B000 C095:C492 562949953453878 /cygdrive/d/WINDOWS/system32/advapi32.dll 77E50000-77E51000 r--p 00000000 C095:C492 4503599627854602 /cygdrive/d/WINDOWS/system32/rpcrt4.dll 77E51000-77EDC000 r-xp 00001000 C095:C492 4503599627854602 /cygdrive/d/WINDOWS/system32/rpcrt4.dll 77EDC000-77EDD000 rw-p 0008C000 C095:C492 4503599627854602 /cygdrive/d/WINDOWS/system32/rpcrt4.dll 77EDD000-77EE3000 r--p 0008D000 C095:C492 4503599627854602 /cygdrive/d/WINDOWS/system32/rpcrt4.dll 77FC0000-77FC1000 r--p 00000000 C095:C492 1125899906874083 /cygdrive/d/WINDOWS/system32/secur32.dll 77FC1000-77FCE000 r-xp 00001000 C095:C492 1125899906874083 /cygdrive/d/WINDOWS/system32/secur32.dll 77FCE000-77FCF000 rw-p 0000E000 C095:C492 1125899906874083 /cygdrive/d/WINDOWS/system32/secur32.dll 77FCF000-77FD1000 r--p 0000F000 C095:C492 1125899906874083 /cygdrive/d/WINDOWS/system32/secur32.dll 7C800000-7C801000 r--p 00000000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C801000-7C885000 r-xp 00001000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C885000-7C88A000 rw-p 00085000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C88A000-7C906000 r--p 0008A000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C910000-7C911000 r--p 00000000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C911000-7C98E000 r-xp 00001000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C98E000-7C993000 rw-p 0007E000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C993000-7C9C9000 r--p 00083000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7F6F0000-7F6F7000 r-xs 00000000 0000:0000 0 7F6F7000-7F7F0000 ===s 00007000 0000:0000 0 7FFB0000-7FFD4000 r--s 00000000 0000:0000 0 7FFDD000-7FFDE000 rw-p 00000000 0000:0000 0 [teb (tid 672)] 7FFDE000-7FFDF000 rw-p 00000000 0000:0000 0 [teb (tid 2652)] 7FFDF000-7FFE0000 rw-p 00000000 0000:0000 0 [peb] 7FFE0000-7FFE1000 r--p 00000000 0000:0000 0 [shared-user-data] 7FFE1000-7FFF0000 ===p 00001000 0000:0000 0 I do not include /proc/{1388,324,492}/maps, i have diff'ed them, they are similar to /proc/4084/maps (same number of lines, same lines except lines beginning with 00 or 7F). I add that i didn't perform any rebase/rebaseall (since fresh install). Hope this helps. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 9:08 ` Denis Excoffier @ 2012-02-08 9:27 ` Corinna Vinschen 2012-02-08 10:23 ` Denis Excoffier 0 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-02-08 9:27 UTC (permalink / raw) To: cygwin On Feb 8 10:08, Denis Excoffier wrote: > Result is: > > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied > 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied > 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied > 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied So both DLLs are in the list twice at the same spot with only different load types? Don't be afraid, but I have to ask a difficult question: Huh? How did that happen? And why doesn't that occur on all systems but only on some?!? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 9:27 ` Corinna Vinschen @ 2012-02-08 10:23 ` Denis Excoffier 2012-02-08 12:33 ` Earnie Boyd ` (2 more replies) 0 siblings, 3 replies; 51+ messages in thread From: Denis Excoffier @ 2012-02-08 10:23 UTC (permalink / raw) To: cygwin On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: >> On Feb 8 10:08, Denis Excoffier wrote: >> > Result is: >> > >> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied >> > 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied >> > 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied >> > 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied >> >> So both DLLs are in the list twice at the same spot with only different >> load types? >> >> Don't be afraid, but I have to ask a difficult question: Huh? >> >> How did that happen? And why doesn't that occur on all systems but only >> on some?!? I can reproduce. On my system (2012-02-07 snapshot instrumented), the following is able to exercise the fork failure any time. I do this from within a dedicated directory named "stc". Current shell seems indifferent. Here it is /bin/tcsh and i've tried with /bin/bash with the same result. % cat doit1 #!/usr/bin/tcsh -f setenv PATH "/usr/bin" cp /usr/bin/cyggcc_s-1.dll . ls rm cyggcc_s-1.dll % % cat doit2 #!/tmp/tcsh -f setenv PATH "/usr/bin" cp /usr/bin/cyggcc_s-1.dll . ls rm cyggcc_s-1.dll % Also you will need to do (once): cp /usr/bin/tcsh.exe /tmp/tcsh.exe % ./doit1 cyggcc_s-1.dll doit1 doit2 % % ./doit2 1 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) 97 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cyggcc_s-1.dll' (0x6BF40000 with type 1=DLL_LINK) 165 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygncurses-10.dll' (0x69580000 with type 1=DLL_LINK) 231 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygcatgets1.dll' (0x70200000 with type 1=DLL_LINK) 298 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cyggcc_s-1.dll' (0x6BF40000 with type 2=DLL_LOAD) 376 [main] tcsh 3660 child_info_fork::abort: address space needed by 'cyggcc_s-1.dll' (0x6BF40000) is already occupied [in the background, and this order: - cp /proc/3660/maps /tmp/3660 - kill 3660 from TaskManager (or wait for 3600s) ] 4 [main] tcsh 1756 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 No more processes. % cd .. % rm stc/cyg* % cd stc % cat /tmp/3660 00010000-00011000 rw-p 00000000 0000:0000 0 00020000-00021000 rw-p 00000000 0000:0000 0 00030000-0020B000 ===p 00000000 0000:0000 0 [stack (tid 3504)] 0020B000-0020C000 rw-g 001DB000 0000:0000 0 [stack (tid 3504)] 0020C000-00230000 rw-p 001DC000 0000:0000 0 [stack (tid 3504)] 00230000-00233000 r--s 00000000 0000:0000 0 00240000-00244000 rw-p 00000000 0000:0000 0 00244000-00340000 ===p 00004000 0000:0000 0 00340000-00346000 rw-p 00000000 0000:0000 0 [win heap 0 default grow] 00346000-00350000 ===p 00006000 0000:0000 0 [win heap 0 default grow] 00350000-00353000 rw-s 00000000 0000:0000 0 [win heap 1 grow] 00353000-00360000 ===s 00003000 0000:0000 0 [win heap 1 grow] 00360000-00376000 r--s 00000000 C095:C492 281474976712054 /cygdrive/d/WINDOWS/system32/unicode.nls 00380000-003C1000 r--s 00000000 C095:C492 281474976713091 /cygdrive/d/WINDOWS/system32/locale.nls 003D0000-003D6000 r--s 00000000 C095:C492 281474976713631 /cygdrive/d/WINDOWS/system32/sorttbls.nls 00400000-00401000 r--p 00000000 C095:C492 22517998136868557 /tmp/tcsh.exe 00401000-00444000 r-xp 00001000 C095:C492 22517998136868557 /tmp/tcsh.exe 00444000-00467000 rw-p 00044000 C095:C492 22517998136868557 /tmp/tcsh.exe 00470000-004B1000 r--s 00000000 C095:C492 281474976713630 /cygdrive/d/WINDOWS/system32/sortkey.nls 004C0000-006BB000 ===p 00000000 0000:0000 0 [stack (tid 1520)] 006BB000-006BC000 rw-g 001FB000 0000:0000 0 [stack (tid 1520)] 006BC000-006C0000 rw-p 001FC000 0000:0000 0 [stack (tid 1520)] 20000000-20070000 rw-p 00000000 0000:0000 0 [heap] 20070000-38000000 ===p 00070000 0000:0000 0 [heap] 60FD0000-60FE0000 rw-s 00000000 0000:0000 0 [procinfo] 60FE0000-60FE9000 rw-s 00000000 0000:0000 0 [cygwin-user-shared] 60FF0000-60FF6000 rw-s 00000000 0000:0000 0 [cygwin-shared] 61000000-61001000 r--p 00000000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 61001000-6117B000 r-xp 00001000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 6117B000-6117D000 rwxp 0017B000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 6117D000-6119D000 rw-p 0017D000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 6119D000-611FC000 r--p 0019D000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 611FC000-61231000 rw-p 001FC000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 61231000-6123B000 r--p 00231000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 6123B000-6123C000 rw-p 0023B000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 6123C000-61256000 r--p 0023C000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 61256000-61261000 rw-p 00256000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 61261000-61262000 r--p 00261000 C095:C492 38280596832707965 /usr/bin/cygwin1.dll 61262000-61470000 rw-p 00262000 C095:C492 38280596832707965 /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 69580000-69581000 r--p 00000000 C095:C492 1407374884187364 /usr/bin/cygncurses-10.dll 69581000-695A2000 r-xp 00001000 C095:C492 1407374884187364 /usr/bin/cygncurses-10.dll 695A2000-695AF000 rw-p 00022000 C095:C492 1407374884187364 /usr/bin/cygncurses-10.dll 695AF000-695B3000 r--p 0002F000 C095:C492 1407374884187364 /usr/bin/cygncurses-10.dll 695B3000-695B4000 rw-p 00033000 C095:C492 1407374884187364 /usr/bin/cygncurses-10.dll 695B4000-695B5000 r--p 00034000 C095:C492 1407374884187364 /usr/bin/cygncurses-10.dll 6BF40000-6BF41000 r--p 00000000 C095:C492 45035996273718856 /cygdrive/d/Home/dexcoff1/dexcoff1/cygscf/stc/cyggcc_s-1.dll 6BF41000-6BF52000 r-xp 00001000 C095:C492 45035996273718856 /cygdrive/d/Home/dexcoff1/dexcoff1/cygscf/stc/cyggcc_s-1.dll 6BF52000-6BF55000 rw-p 00012000 C095:C492 45035996273718856 /cygdrive/d/Home/dexcoff1/dexcoff1/cygscf/stc/cyggcc_s-1.dll 6BF55000-6BF56000 r--p 00015000 C095:C492 45035996273718856 /cygdrive/d/Home/dexcoff1/dexcoff1/cygscf/stc/cyggcc_s-1.dll 6BF56000-6BF57000 rw-p 00016000 C095:C492 45035996273718856 /cygdrive/d/Home/dexcoff1/dexcoff1/cygscf/stc/cyggcc_s-1.dll 6BF57000-6BF58000 r--p 00017000 C095:C492 45035996273718856 /cygdrive/d/Home/dexcoff1/dexcoff1/cygscf/stc/cyggcc_s-1.dll 70200000-70201000 r--p 00000000 C095:C492 1970324837587761 /usr/bin/cygcatgets1.dll 70201000-70203000 r-xp 00001000 C095:C492 1970324837587761 /usr/bin/cygcatgets1.dll 70203000-70206000 rw-p 00003000 C095:C492 1970324837587761 /usr/bin/cygcatgets1.dll 70206000-70207000 r--p 00006000 C095:C492 1970324837587761 /usr/bin/cygcatgets1.dll 70207000-70208000 rw-p 00007000 C095:C492 1970324837587761 /usr/bin/cygcatgets1.dll 70208000-70209000 r--p 00008000 C095:C492 1970324837587761 /usr/bin/cygcatgets1.dll 7C800000-7C801000 r--p 00000000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C801000-7C885000 r-xp 00001000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C885000-7C88A000 rw-p 00085000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C88A000-7C906000 r--p 0008A000 C095:C492 562949953454378 /cygdrive/d/WINDOWS/system32/kernel32.dll 7C910000-7C911000 r--p 00000000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C911000-7C98E000 r-xp 00001000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C98E000-7C993000 rw-p 0007E000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7C993000-7C9C9000 r--p 00083000 C095:C492 2533274790880158 /cygdrive/d/WINDOWS/system32/ntdll.dll 7F6F0000-7F6F7000 r-xs 00000000 0000:0000 0 7F6F7000-7F7F0000 ===s 00007000 0000:0000 0 7FFB0000-7FFD4000 r--s 00000000 0000:0000 0 7FFDD000-7FFDE000 rw-p 00000000 0000:0000 0 [teb (tid 1520)] 7FFDE000-7FFDF000 rw-p 00000000 0000:0000 0 [teb (tid 3504)] 7FFDF000-7FFE0000 rw-p 00000000 0000:0000 0 [peb] 7FFE0000-7FFE1000 r--p 00000000 0000:0000 0 [shared-user-data] 7FFE1000-7FFF0000 ===p 00001000 0000:0000 0 % rm /tmp/3660 % Hope this helps. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 10:23 ` Denis Excoffier @ 2012-02-08 12:33 ` Earnie Boyd 2012-02-08 13:00 ` Corinna Vinschen 2012-03-04 17:22 ` Corinna Vinschen 2 siblings, 0 replies; 51+ messages in thread From: Earnie Boyd @ 2012-02-08 12:33 UTC (permalink / raw) To: cygwin On Wed, Feb 8, 2012 at 5:22 AM, Denis Excoffier wrote: > > I can reproduce. > > On my system (2012-02-07 snapshot instrumented), the following is able > to exercise the fork failure any time. > > I do this from within a dedicated directory named "stc". > Current shell seems indifferent. Here it is /bin/tcsh and > i've tried with /bin/bash with the same result. > > % cat doit1 > #!/usr/bin/tcsh -f > setenv PATH "/usr/bin" > cp /usr/bin/cyggcc_s-1.dll . > ls > rm cyggcc_s-1.dll > % This is not going to work, period. When you copy a DLL to the working directory it will be that DLL that is used instead of the previously loaded DLL. It is the way the DLL search order works. You'll see failures and perhaps even lock up your OS. Try this with the CYGWIN DLL and you'll not be able to ls or rm. > > Hope this helps. > Ditto, -- Earnie -- https://sites.google.com/site/earnieboyd -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 10:23 ` Denis Excoffier 2012-02-08 12:33 ` Earnie Boyd @ 2012-02-08 13:00 ` Corinna Vinschen 2012-02-08 13:35 ` Corinna Vinschen 2012-03-04 17:22 ` Corinna Vinschen 2 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-02-08 13:00 UTC (permalink / raw) To: cygwin On Feb 8 11:22, Denis Excoffier wrote: > I can reproduce. > > On my system (2012-02-07 snapshot instrumented), the following is able > to exercise the fork failure any time. > > I do this from within a dedicated directory named "stc". > Current shell seems indifferent. Here it is /bin/tcsh and > i've tried with /bin/bash with the same result. > > % cat doit1 > #!/usr/bin/tcsh -f > setenv PATH "/usr/bin" > cp /usr/bin/cyggcc_s-1.dll . > ls > rm cyggcc_s-1.dll > % > % cat doit2 > #!/tmp/tcsh -f > setenv PATH "/usr/bin" > cp /usr/bin/cyggcc_s-1.dll . > ls > rm cyggcc_s-1.dll > % > > Also you will need to do (once): cp /usr/bin/tcsh.exe /tmp/tcsh.exe > > > % ./doit1 > cyggcc_s-1.dll doit1 doit2 > % > % ./doit2 > 1 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) > [...etc...] Thanks for the testcase! I can reproduce now as well. I think I see what's going wrong, but I'm not quite sure what the best fix is. Stay tuned. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 13:00 ` Corinna Vinschen @ 2012-02-08 13:35 ` Corinna Vinschen 2012-02-08 14:25 ` Heiko Elger 2012-02-08 14:55 ` Denis Excoffier 0 siblings, 2 replies; 51+ messages in thread From: Corinna Vinschen @ 2012-02-08 13:35 UTC (permalink / raw) To: cygwin On Feb 8 14:00, Corinna Vinschen wrote: > On Feb 8 11:22, Denis Excoffier wrote: > > I can reproduce. > > > > On my system (2012-02-07 snapshot instrumented), the following is able > > to exercise the fork failure any time. > > > > I do this from within a dedicated directory named "stc". > > Current shell seems indifferent. Here it is /bin/tcsh and > > i've tried with /bin/bash with the same result. > > > > % cat doit1 > > #!/usr/bin/tcsh -f > > setenv PATH "/usr/bin" > > cp /usr/bin/cyggcc_s-1.dll . > > ls > > rm cyggcc_s-1.dll > > % > > % cat doit2 > > #!/tmp/tcsh -f > > setenv PATH "/usr/bin" > > cp /usr/bin/cyggcc_s-1.dll . > > ls > > rm cyggcc_s-1.dll > > % > > > > Also you will need to do (once): cp /usr/bin/tcsh.exe /tmp/tcsh.exe > > > > > > % ./doit1 > > cyggcc_s-1.dll doit1 doit2 > > % > > % ./doit2 > > 1 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) > > [...etc...] > > Thanks for the testcase! I can reproduce now as well. I think I see > what's going wrong, but I'm not quite sure what the best fix is. Stay > tuned. What happens in this testcase is that Cygwin checks the full DLL path and then finds that the new path to cyggcc_s-1.dll is not the same as the path it has already loaded. Therefore it assumes that it has to add the file to list. This is plainly wrong, because, as you can read on http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx the Windows loader does not load a DLL again, if it already has a module loaded which has the same basename. Therefore the test for the full pathname in Cygwin has to to be replaced with only testing the module basename. However, while this situation in the doit2 testcase is simply explained, I don't see how this affects your rsync call. Denis, can you please change your test output? Instead of printing only d_alt->modname, please print d_alt->name and then run your rsync test again. If this is the same problem as in the doit testcase, I'd like to see where the second cygiconv-2.dll is coming from. In theory, if you have only a single installation of cygiconv-2.dll, this should'nt happen. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 13:35 ` Corinna Vinschen @ 2012-02-08 14:25 ` Heiko Elger 2012-02-08 14:37 ` Corinna Vinschen 2012-03-04 17:23 ` Corinna Vinschen 2012-02-08 14:55 ` Denis Excoffier 1 sibling, 2 replies; 51+ messages in thread From: Heiko Elger @ 2012-02-08 14:25 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > > What happens in this testcase is that Cygwin checks the full DLL path > and then finds that the new path to cyggcc_s-1.dll is not the same as > the path it has already loaded. Therefore it assumes that it has to add > the file to list. > > This is plainly wrong, because, as you can read on > http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx the > Windows loader does not load a DLL again, if it already has a module > loaded which has the same basename. Therefore the test for the full > pathname in Cygwin has to to be replaced with only testing the module > basename. > > However, while this situation in the doit2 testcase is simply explained, > I don't see how this affects your rsync call. > > Denis, can you please change your test output? Instead of printing only > d_alt->modname, please print d_alt->name and then run your rsync test > again. If this is the same problem as in the doit testcase, I'd like to > see where the second cygiconv-2.dll is coming from. In theory, if you > have only a single installation of cygiconv-2.dll, this should'nt > happen. Hello, just one more question concerning the problem of loading dlls twice. We installed cygwin into c:\Programme\cygwin 1) c:\programme is a symbolic link (like junction of sysinternal tools) to "c:\Program Files" via MKLINK /J and 2) c:\Programme is a WINDOWS7 language German localized link/substition/ or whatever to "c:\Program Files" too. Can this be a problem for cygwin too - concerning the problem of this thread? 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 14:25 ` Heiko Elger @ 2012-02-08 14:37 ` Corinna Vinschen 2012-03-04 17:23 ` Corinna Vinschen 1 sibling, 0 replies; 51+ messages in thread From: Corinna Vinschen @ 2012-02-08 14:37 UTC (permalink / raw) To: cygwin On Feb 8 14:24, Heiko Elger wrote: > Corinna Vinschen writes: > > > > > What happens in this testcase is that Cygwin checks the full DLL path > > and then finds that the new path to cyggcc_s-1.dll is not the same as > > the path it has already loaded. Therefore it assumes that it has to add > > the file to list. > > > > This is plainly wrong, because, as you can read on > > http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx the > > Windows loader does not load a DLL again, if it already has a module > > loaded which has the same basename. Therefore the test for the full > > pathname in Cygwin has to to be replaced with only testing the module > > basename. > > > > However, while this situation in the doit2 testcase is simply explained, > > I don't see how this affects your rsync call. > > > > Denis, can you please change your test output? Instead of printing only > > d_alt->modname, please print d_alt->name and then run your rsync test > > again. If this is the same problem as in the doit testcase, I'd like to > > see where the second cygiconv-2.dll is coming from. In theory, if you > > have only a single installation of cygiconv-2.dll, this should'nt > > happen. > > Hello, > > just one more question concerning the problem of loading dlls twice. > We installed cygwin into c:\Programme\cygwin > 1) c:\programme is a symbolic link (like junction of sysinternal tools) > to "c:\Program Files" via MKLINK /J > and > 2) c:\Programme is a WINDOWS7 language German localized link/substition/ or > whatever to "c:\Program Files" too. > > Can this be a problem for cygwin too - concerning the problem of this thread? AFAICS, yes. That could be part of the problem. The path to DLLs is not normalized by the Windows loader before it's stored in the DLL list, and the GetModuleFileName function returns the path as stored. If the DLL has been loaded using one path, and then, in the forkee, is found using the other path, that would explain a collision. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 14:25 ` Heiko Elger 2012-02-08 14:37 ` Corinna Vinschen @ 2012-03-04 17:23 ` Corinna Vinschen 1 sibling, 0 replies; 51+ messages in thread From: Corinna Vinschen @ 2012-03-04 17:23 UTC (permalink / raw) To: cygwin On Feb 8 14:24, Heiko Elger wrote: > Corinna Vinschen writes: > > > > > What happens in this testcase is that Cygwin checks the full DLL path > > and then finds that the new path to cyggcc_s-1.dll is not the same as > > the path it has already loaded. Therefore it assumes that it has to add > > the file to list. > > > > This is plainly wrong, because, as you can read on > > http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx the > > Windows loader does not load a DLL again, if it already has a module > > loaded which has the same basename. Therefore the test for the full > > pathname in Cygwin has to to be replaced with only testing the module > > basename. > > > > However, while this situation in the doit2 testcase is simply explained, > > I don't see how this affects your rsync call. > > > > Denis, can you please change your test output? Instead of printing only > > d_alt->modname, please print d_alt->name and then run your rsync test > > again. If this is the same problem as in the doit testcase, I'd like to > > see where the second cygiconv-2.dll is coming from. In theory, if you > > have only a single installation of cygiconv-2.dll, this should'nt > > happen. > > Hello, > > just one more question concerning the problem of loading dlls twice. > We installed cygwin into c:\Programme\cygwin > 1) c:\programme is a symbolic link (like junction of sysinternal tools) > to "c:\Program Files" via MKLINK /J > and > 2) c:\Programme is a WINDOWS7 language German localized link/substition/ or > whatever to "c:\Program Files" too. > > Can this be a problem for cygwin too - concerning the problem of this thread? Heiko, can you please test the latests snapshot DLL in your envionment? The latest changes should handle this scenarion gracefully, but testing never hurts, right? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 13:35 ` Corinna Vinschen 2012-02-08 14:25 ` Heiko Elger @ 2012-02-08 14:55 ` Denis Excoffier 2012-02-08 15:06 ` Heiko Elger 2012-02-08 15:16 ` Corinna Vinschen 1 sibling, 2 replies; 51+ messages in thread From: Denis Excoffier @ 2012-02-08 14:55 UTC (permalink / raw) To: cygwin On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote: >> On Feb 8 14:00, Corinna Vinschen wrote: >> > On Feb 8 11:22, Denis Excoffier wrote: >> > > I can reproduce. >> > > >> > > On my system (2012-02-07 snapshot instrumented), the following is able >> > > to exercise the fork failure any time. >> > > >> > > I do this from within a dedicated directory named "stc". >> > > Current shell seems indifferent. Here it is /bin/tcsh and >> > > i've tried with /bin/bash with the same result. >> > > >> > > % cat doit1 >> > > #!/usr/bin/tcsh -f >> > > setenv PATH "/usr/bin" >> > > cp /usr/bin/cyggcc_s-1.dll . >> > > ls >> > > rm cyggcc_s-1.dll >> > > % >> > > % cat doit2 >> > > #!/tmp/tcsh -f >> > > setenv PATH "/usr/bin" >> > > cp /usr/bin/cyggcc_s-1.dll . >> > > ls >> > > rm cyggcc_s-1.dll >> > > % >> > > >> > > Also you will need to do (once): cp /usr/bin/tcsh.exe /tmp/tcsh.exe >> > > >> > > >> > > % ./doit1 >> > > cyggcc_s-1.dll doit1 doit2 >> > > % >> > > % ./doit2 >> > > 1 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) >> > > [...etc...] >> > >> > Thanks for the testcase! I can reproduce now as well. I think I see >> > what's going wrong, but I'm not quite sure what the best fix is. Stay >> > tuned. >> >> What happens in this testcase is that Cygwin checks the full DLL path >> and then finds that the new path to cyggcc_s-1.dll is not the same as >> the path it has already loaded. Therefore it assumes that it has to add >> the file to list. >> >> This is plainly wrong, because, as you can read on >> http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx the >> Windows loader does not load a DLL again, if it already has a module >> loaded which has the same basename. Therefore the test for the full >> pathname in Cygwin has to to be replaced with only testing the module >> basename. >> >> However, while this situation in the doit2 testcase is simply explained, >> I don't see how this affects your rsync call. >> >> Denis, can you please change your test output? Instead of printing only >> d_alt->modname, please print d_alt->name and then run your rsync test >> again. If this is the same problem as in the doit testcase, I'd like to >> see where the second cygiconv-2.dll is coming from. In theory, if you >> have only a single installation of cygiconv-2.dll, this should'nt >> happen. Here it is. Enjoy! 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 1=DLL_LINK) 1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 1=DLL_LINK) 1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 2=DLL_LOAD) 2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 2=DLL_LOAD) 3290 [main] gcc-4 5440 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 I don't think you will need /proc/5440/maps this time. Regards, Denis. -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 14:55 ` Denis Excoffier @ 2012-02-08 15:06 ` Heiko Elger 2012-02-08 15:35 ` Denis Excoffier 2012-02-08 15:16 ` Corinna Vinschen 1 sibling, 1 reply; 51+ messages in thread From: Heiko Elger @ 2012-02-08 15:06 UTC (permalink / raw) To: cygwin Denis Excoffier writes: > Here it is. Enjoy! > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 1=DLL_LINK) > 1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 1=DLL_LINK) > 1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 2=DLL_LOAD) > 2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 2=DLL_LOAD) > 3290 [main] gcc-4 5440 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) > is already occupied > 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 > Hello Denis, thanks a lot for your testing ... Is is possible to send me the snapshot patches responsible for this output. I solved my personal forked problem http://thread.gmane.org/gmane.os.cygwin/130982 - the problem was running peflagsall. But now I have a similar fork perl problem http://thread.gmane.org/gmane.os.cygwin/131091. To diagnose the problem a little bit deeper - perhaps your instrumented code will help. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 15:06 ` Heiko Elger @ 2012-02-08 15:35 ` Denis Excoffier 0 siblings, 0 replies; 51+ messages in thread From: Denis Excoffier @ 2012-02-08 15:35 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1408 bytes --] On Wed, Feb 08, 2012 at 03:05:33PM +0000, Heiko Elger wrote: >> Denis Excoffier writes: >> >> > Here it is. Enjoy! >> > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> by 'cygiconv-2.dll' (file >> > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with >> type 1=DLL_LINK) >> > 1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> by 'cygintl-8.dll' (file >> > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with >> type 1=DLL_LINK) >> > 1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> by 'cygiconv-2.dll' (file >> > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 >> with type 2=DLL_LOAD) >> > 2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> by 'cygintl-8.dll' (file >> > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 >> with type 2=DLL_LOAD) >> > 3290 [main] gcc-4 5440 child_info_fork::abort: address space needed >> by 'cygiconv-2.dll' (0x674C0000) >> > is already occupied >> > 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, >> retry 0, exit code 1, errno 11 >> > >> >> Hello Denis, >> >> thanks a lot for your testing ... >> >> Is is possible to send me the snapshot patches responsible for this output. Here it is (attached). Good luck. Denis Excoffier. [-- Attachment #2: instrument.patch --] [-- Type: text/plain, Size: 1354 bytes --] diff -cNr 0/dll_init.cc 1/dll_init.cc *** 0/dll_init.cc Wed Feb 8 16:10:49 2012 --- 1/dll_init.cc Wed Feb 8 16:17:40 2012 *************** *** 426,434 **** dll_list::reserve_space () { for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ()) ! if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) fabort ("address space needed by '%W' (%p) is already occupied", d->modname, d->handle); } /* Reload DLLs after a fork. Iterates over the list of dynamically loaded --- 426,440 ---- dll_list::reserve_space () { for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ()) ! #define TYPE_SHOW(x) ((x) == DLL_NONE) ? "DLL_NONE" : ((x) == DLL_LINK) ? "DLL_LINK" : ((x) == DLL_LOAD) ? "DLL_LOAD" : ((x) == DLL_ANY) ? "DLL_ANY" : "DLL_(unknown)" ! if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) { ! for (dll* d_alt = dlls.start.next; d_alt; d_alt = d_alt->next) { ! system_printf ("address space needed by '%W' (file %W) (%p with type %d=%s)", ! d_alt->modname, d_alt->name, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type)); ! }; fabort ("address space needed by '%W' (%p) is already occupied", d->modname, d->handle); + }; } /* Reload DLLs after a fork. Iterates over the list of dynamically loaded [-- Attachment #3: Type: text/plain, Size: 218 bytes --] -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 14:55 ` Denis Excoffier 2012-02-08 15:06 ` Heiko Elger @ 2012-02-08 15:16 ` Corinna Vinschen 2012-02-09 11:07 ` Corinna Vinschen 1 sibling, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-02-08 15:16 UTC (permalink / raw) To: cygwin On Feb 8 15:55, Denis Excoffier wrote: > On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote: > >> Denis, can you please change your test output? Instead of printing only > >> d_alt->modname, please print d_alt->name and then run your rsync test > >> again. If this is the same problem as in the doit testcase, I'd like to > >> see where the second cygiconv-2.dll is coming from. In theory, if you > >> have only a single installation of cygiconv-2.dll, this should'nt > >> happen. > Here it is. Enjoy! > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 1=DLL_LINK) > 1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 1=DLL_LINK) > 1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 2=DLL_LOAD) > 2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 2=DLL_LOAD) > 3290 [main] gcc-4 5440 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied > 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 > > I don't think you will need /proc/5440/maps this time. Nope, thank you. Look at this: D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll So it's the same DLL path, just one time with the long pathname prefix (or better: The Win32 equivalent to the native NT path prefix). But, as I wrote in my mail to Heiko, neither the Windows loader nor the GetModuleFileName call normalize the path. So I think I just apply my patch to use only the basename in the dll_init code. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 15:16 ` Corinna Vinschen @ 2012-02-09 11:07 ` Corinna Vinschen 2012-02-09 13:40 ` Denis Excoffier 0 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-02-09 11:07 UTC (permalink / raw) To: cygwin On Feb 8 16:16, Corinna Vinschen wrote: > On Feb 8 15:55, Denis Excoffier wrote: > > On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote: > > >> Denis, can you please change your test output? Instead of printing only > > >> d_alt->modname, please print d_alt->name and then run your rsync test > > >> again. If this is the same problem as in the doit testcase, I'd like to > > >> see where the second cygiconv-2.dll is coming from. In theory, if you > > >> have only a single installation of cygiconv-2.dll, this should'nt > > >> happen. > > Here it is. Enjoy! > > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 1=DLL_LINK) > > 1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 1=DLL_LINK) > > 1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 2=DLL_LOAD) > > 2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 2=DLL_LOAD) > > 3290 [main] gcc-4 5440 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied > > 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 > > > > I don't think you will need /proc/5440/maps this time. > > Nope, thank you. Look at this: > > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll > > So it's the same DLL path, just one time with the long pathname prefix > (or better: The Win32 equivalent to the native NT path prefix). But, > as I wrote in my mail to Heiko, neither the Windows loader nor the > GetModuleFileName call normalize the path. So I think I just apply > my patch to use only the basename in the dll_init code. I applied a patch and generated a new snapshot. Please give it a try. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-09 11:07 ` Corinna Vinschen @ 2012-02-09 13:40 ` Denis Excoffier 2012-02-09 14:44 ` Denis Excoffier 2012-02-09 14:44 ` Corinna Vinschen 0 siblings, 2 replies; 51+ messages in thread From: Denis Excoffier @ 2012-02-09 13:40 UTC (permalink / raw) To: cygwin On Thu, Feb 09, 2012 at 12:06:31PM +0100, Corinna Vinschen wrote: >> On Feb 8 16:16, Corinna Vinschen wrote: >> > On Feb 8 15:55, Denis Excoffier wrote: >> > > On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote: >> > > >> Denis, can you please change your test output? Instead of printing only >> > > >> d_alt->modname, please print d_alt->name and then run your rsync test >> > > >> again. If this is the same problem as in the doit testcase, I'd like to >> > > >> see where the second cygiconv-2.dll is coming from. In theory, if you >> > > >> have only a single installation of cygiconv-2.dll, this should'nt >> > > >> happen. >> > > Here it is. Enjoy! >> > > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 1=DLL_LINK) >> > > 1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 1=DLL_LINK) >> > > 1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C0000 with type 2=DLL_LOAD) >> > > 2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C0000 with type 2=DLL_LOAD) >> > > 3290 [main] gcc-4 5440 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C0000) is already occupied >> > > 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 >> > > >> > > I don't think you will need /proc/5440/maps this time. >> > >> > Nope, thank you. Look at this: >> > >> > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll >> > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll >> > >> > So it's the same DLL path, just one time with the long pathname prefix >> > (or better: The Win32 equivalent to the native NT path prefix). But, >> > as I wrote in my mail to Heiko, neither the Windows loader nor the >> > GetModuleFileName call normalize the path. So I think I just apply >> > my patch to use only the basename in the dll_init code. >> >> I applied a patch and generated a new snapshot. Please give it a try. Usually after installation of a new snapshot i begin with a compilation of the sources. Today the compilation fails in winsup/cygwin/mkimport (perl script) with the following messages: 1 [main] perl 2380 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 5460 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 5 [main] perl 5916 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 4028 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 4 [main] perl 4900 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 2128 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 4 [main] perl 5120 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 5440 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 4 [main] perl 5044 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 5456 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 etc. at the pace one message each 5seconds. All processes indicated remain in /proc, as <defunct>, and with maps "permission denied". 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-09 13:40 ` Denis Excoffier @ 2012-02-09 14:44 ` Denis Excoffier 2012-02-09 14:44 ` Corinna Vinschen 1 sibling, 0 replies; 51+ messages in thread From: Denis Excoffier @ 2012-02-09 14:44 UTC (permalink / raw) To: cygwin On Thu, Feb 09, 2012 at 02:37:58PM +0059, Denis Excoffier wrote: >> >> Usually after installation of a new snapshot i begin with a compilation >> of the sources. Today the compilation fails in winsup/cygwin/mkimport >> (perl script) with the following messages: >> 1 [main] perl 2380 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 >> 4 [main] perl 5460 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 >> 5 [main] perl 5916 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 >> 4 [main] perl 4028 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 >> 4 [main] perl 4900 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 >> 4 [main] perl 2128 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 >> 4 [main] perl 5120 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 >> 4 [main] perl 5440 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 >> 4 [main] perl 5044 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 >> 4 [main] perl 5456 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 >> etc. >> >> at the pace one message each 5seconds. >> All processes indicated remain in /proc, as <defunct>, and with >> maps "permission denied". The parent process can have its maps displayed, it contains: ... 5416D000-54177000 r--p 0016D000 C095:C492 562949954111930 /usr/bin/cygperl5_10.dll 54210000-54211000 r--p 00000000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54211000-54214000 r-xp 00001000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54214000-54215000 rw-p 00004000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54215000-54216000 r--p 00005000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54216000-54218000 rw-p 00006000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54218000-54219000 r--p 00008000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54219000-5421A000 rw-p 00009000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 5421A000-5421C000 r--p 0000A000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54680000-54681000 r--p 00000000 C095:C492 562949954112354 /usr/lib/perl5/5.10/i686-cygwin/auto/Fcntl/Fcntl.dll ... 54688000-5468A000 r--p 00008000 C095:C492 562949954112354 /usr/lib/perl5/5.10/i686-cygwin/auto/Fcntl/Fcntl.dll 54690000-54691000 r--p 00000000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54691000-54695000 r-xp 00001000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54695000-54696000 rw-p 00005000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54696000-54697000 r--p 00006000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54697000-54699000 rw-p 00007000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54699000-5469A000 r--p 00009000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 5469A000-5469B000 rw-p 0000A000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 5469B000-5469D000 r--p 0000B000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54700000-54701000 r--p 00000000 C095:C492 562949954112374 /usr/lib/perl5/5.10/i686-cygwin/auto/IO/IO.dll ... and 54210000 and 54690000 are OK iaw objdump -h I will add that i cannot instrument myself... 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-09 13:40 ` Denis Excoffier 2012-02-09 14:44 ` Denis Excoffier @ 2012-02-09 14:44 ` Corinna Vinschen 2012-02-10 12:35 ` Andrey Repin 2012-02-13 13:48 ` Scott M. Ballew 1 sibling, 2 replies; 51+ messages in thread From: Corinna Vinschen @ 2012-02-09 14:44 UTC (permalink / raw) To: cygwin On Feb 9 14:37, Denis Excoffier wrote: > On Thu, Feb 09, 2012 at 12:06:31PM +0100, Corinna Vinschen wrote: > >> > So it's the same DLL path, just one time with the long pathname prefix > >> > (or better: The Win32 equivalent to the native NT path prefix). But, > >> > as I wrote in my mail to Heiko, neither the Windows loader nor the > >> > GetModuleFileName call normalize the path. So I think I just apply > >> > my patch to use only the basename in the dll_init code. > >> > >> I applied a patch and generated a new snapshot. Please give it a try. > > Usually after installation of a new snapshot i begin with a compilation > of the sources. Today the compilation fails in winsup/cygwin/mkimport > (perl script) with the following messages: > 1 [main] perl 2380 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 > 4 [main] perl 5460 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 > 5 [main] perl 5916 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 > 4 [main] perl 4028 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 > 4 [main] perl 4900 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 > 4 [main] perl 2128 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 > 4 [main] perl 5120 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 > 4 [main] perl 5440 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 > 4 [main] perl 5044 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 > 4 [main] perl 5456 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 > etc. > > at the pace one message each 5seconds. > All processes indicated remain in /proc, as <defunct>, and with > maps "permission denied". Sigh. While the basename is all we need to test if a DLL is already loaded, it's *not* enough to load a DLL which still needs loading, if the DLLs are not in the DLL search path, as in the case of Perl libs. I'm going to generate a new 2012-02-09 snapshot right now. Should be up in 10 minutes or so. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-09 14:44 ` Corinna Vinschen @ 2012-02-10 12:35 ` Andrey Repin 2012-02-13 13:48 ` Scott M. Ballew 1 sibling, 0 replies; 51+ messages in thread From: Andrey Repin @ 2012-02-10 12:35 UTC (permalink / raw) To: Corinna Vinschen Greetings, Corinna Vinschen! > Sigh. While the basename is all we need to test if a DLL is already > loaded, it's *not* enough to load a DLL which still needs loading, > if the DLLs are not in the DLL search path, as in the case of Perl libs. Unless it is registered in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\ Which, however, counts as "DLL search path" for Windows. Not that it is related to subject, rather - something to keep in mind. -- WBR, Andrey Repin (anrdaemon@freemail.ru) 10.02.2012, <16:20> Sorry for my terrible english... -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-09 14:44 ` Corinna Vinschen 2012-02-10 12:35 ` Andrey Repin @ 2012-02-13 13:48 ` Scott M. Ballew 2012-02-23 16:30 ` Richard Gribble 1 sibling, 1 reply; 51+ messages in thread From: Scott M. Ballew @ 2012-02-13 13:48 UTC (permalink / raw) To: cygwin Corinna Vinschen-2 wrote: > > > Sigh. While the basename is all we need to test if a DLL is already > loaded, it's *not* enough to load a DLL which still needs loading, if > the DLLs are not in the DLL search path, as in the case of Perl libs. > I'm going to generate a new 2012-02-09 snapshot right now. Should be > up in 10 minutes or so. > > I'm happy to report that after I dropped this new snapshot in place, my original problem has gone away completely (and I've been clean for a few days, now). In fact, it also made it so that I could build some software from sources (make and gcc were failing variously with the same type of error messages). So as of now, I am a very happy camper! Thanks much! Scott M. Ballew Purdue University -- View this message in context: http://old.nabble.com/cygwin-1.7.10-1-fork---address-space-needed-by-...-already-in-use-tp33279157p33314949.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-13 13:48 ` Scott M. Ballew @ 2012-02-23 16:30 ` Richard Gribble 2012-02-23 17:23 ` Corinna Vinschen 0 siblings, 1 reply; 51+ messages in thread From: Richard Gribble @ 2012-02-23 16:30 UTC (permalink / raw) To: cygwin Scott M. Ballew <smb <at> purdue.edu> writes: > > > Corinna Vinschen-2 wrote: > > > > > > Sigh. While the basename is all we need to test if a DLL is already > > loaded, it's *not* enough to load a DLL which still needs loading, if > > the DLLs are not in the DLL search path, as in the case of Perl libs. > > I'm going to generate a new 2012-02-09 snapshot right now. Should be > > up in 10 minutes or so. > > > > > > I'm happy to report that after I dropped this new snapshot in place, my > original problem has gone away completely (and I've been clean for a few > days, now). In fact, it also made it so that I could build some software > from sources (make and gcc were failing variously with the same type of > error messages). So as of now, I am a very happy camper! > > Thanks much! > > Scott M. Ballew > Purdue University > I downloaded the source today (23 Feb 2012) and have the error(s) as follows: 2 [main] sh 10184 child_info_fork::abort: address space needed by 'cygicon v-2.dll' (0x674C0000) is already occupied 5 [main] sh 4640 child_info_fork::abort: address space needed by 'cygiconv -2.dll' (0x674C0000) is already occupied 5 [main] sh 1264 child_info_fork::abort: address space needed by 'cygiconv -2.dll' (0x674C0000) is already occupied 5 [main] sh 8072 child_info_fork::abort: address space needed by 'cygiconv -2.dll' (0x674C0000) is already occupied 5 [main] sh 8276 child_info_fork::abort: address space needed by 'cygiconv -2.dll' (0x674C0000) is already occupied I think those are the same errors in the rest of the thread - so how do I go about getting the snapshot so I can be a happy camper too? (I'm working on a problem where I cannot use co to checkout rcs on a network drive.) Thanks, Richard Gribble, FAA. -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-23 16:30 ` Richard Gribble @ 2012-02-23 17:23 ` Corinna Vinschen 0 siblings, 0 replies; 51+ messages in thread From: Corinna Vinschen @ 2012-02-23 17:23 UTC (permalink / raw) To: cygwin On Feb 23 16:25, Richard Gribble wrote: > Scott M. Ballew <smb <at> purdue.edu> writes: > > I'm happy to report that after I dropped this new snapshot in place, my > > original problem has gone away completely (and I've been clean for a few > > days, now). In fact, it also made it so that I could build some software > > from sources (make and gcc were failing variously with the same type of > > error messages). So as of now, I am a very happy camper! > > [...] > > I downloaded the source today (23 Feb 2012) and have the error(s) as follows: What source? > 2 [main] sh 10184 child_info_fork::abort: address space needed by 'cygicon > v-2.dll' (0x674C0000) is already occupied > 5 [main] sh 4640 child_info_fork::abort: address space needed by 'cygiconv > -2.dll' (0x674C0000) is already occupied > 5 [main] sh 1264 child_info_fork::abort: address space needed by 'cygiconv > -2.dll' (0x674C0000) is already occupied > 5 [main] sh 8072 child_info_fork::abort: address space needed by 'cygiconv > -2.dll' (0x674C0000) is already occupied > 5 [main] sh 8276 child_info_fork::abort: address space needed by 'cygiconv > -2.dll' (0x674C0000) is already occupied > > I think those are the same errors in the rest of the thread - so how do I go > about getting the snapshot so I can be a happy camper too? (I'm working on a > problem where I cannot use co to checkout rcs on a network drive.) http://cygwin.com/snapshots/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-02-08 10:23 ` Denis Excoffier 2012-02-08 12:33 ` Earnie Boyd 2012-02-08 13:00 ` Corinna Vinschen @ 2012-03-04 17:22 ` Corinna Vinschen 2012-03-05 7:09 ` Denis Excoffier 2 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-03-04 17:22 UTC (permalink / raw) To: cygwin On Feb 8 11:22, Denis Excoffier wrote: > On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: > >> On Feb 8 10:08, Denis Excoffier wrote: > >> > Result is: > >> > > >> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied > >> > 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied > >> > 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied > >> > 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied Denis, can you please give the latest snapshot DLL a try in all circumstances in which you saw the above kind of fork problems in 1.7.10? I applied a patch which should now work out the differences between linked and loaded DLLs better than before. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-04 17:22 ` Corinna Vinschen @ 2012-03-05 7:09 ` Denis Excoffier 2012-03-05 10:00 ` Corinna Vinschen 0 siblings, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-03-05 7:09 UTC (permalink / raw) To: cygwin On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote: >> On Feb 8 11:22, Denis Excoffier wrote: >> > On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: >> > >> On Feb 8 10:08, Denis Excoffier wrote: >> > >> > Result is: >> > >> > >> > >> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied >> > >> > 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied >> > >> > 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied >> > >> > 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied >> >> Denis, can you please give the latest snapshot DLL a try in all >> circumstances in which you saw the above kind of fork problems in >> 1.7.10? I applied a patch which should now work out the differences >> between linked and loaded DLLs better than before. >> % uname -a CYGWIN_NT-5.1 edited 1.7.12s(0.260/5/3) 20120304 17:49:39 i686 Cygwin % I am now unable to report any problem of that sort. I have compiled the cygwin1.dll, the new gcc-4.7.0-rc-20120302, and several other packages with no occurrence of such a message. I've only to report that i observe some time to time the "something failed for pid" message (see several instances below). "Win32 Error 5" is ERROR_ACCESS_DENIED i suppose (in winerrors.h). I don't know what we are expected to do with these. In addition, they do not seem to hurt much. Also i've to say that i've installed the CYGWIN=detect_bloda and nothing has shown up (still). Regards, Denis Excoffier. 947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0: res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 2 [main] sh 3360! _pinfo::dup_proc_pipe: something failed for pid 0: res 3360, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1345 [main] sh 3772! _pinfo::dup_proc_pipe: something failed for pid 0: res 3772, hProcess 0x6CC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 2 [main] sh 792! _pinfo::dup_proc_pipe: something failed for pid 0: res 792, hProcess 0x6D0, wr_proc_pipe 0x75C vs. 0x75C, Win32 error 5 1 [main] sh 3328! _pinfo::dup_proc_pipe: something failed for pid 0: res 3328, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] sh 1980! _pinfo::dup_proc_pipe: something failed for pid 0: res 1980, hProcess 0x6BC, wr_proc_pipe 0x74C vs. 0x74C, Win32 error 5 1 [main] sh 628! _pinfo::dup_proc_pipe: something failed for pid 0: res 628, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] sh 856! _pinfo::dup_proc_pipe: something failed for pid 0: res 856, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] tcsh 3300! _pinfo::dup_proc_pipe: something failed for pid 0: res 3300, hProcess 0x6F0, wr_proc_pipe 0x768 vs. 0x768, Win32 error 5 >> >> Thanks, >> Corinna >> >> -- >> Corinna Vinschen Please, send mails regarding Cygwin to >> Cygwin Project Co-Leader cygwin AT cygwin DOT com >> Red Hat >> >> -- >> 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 -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-05 7:09 ` Denis Excoffier @ 2012-03-05 10:00 ` Corinna Vinschen 2012-03-05 12:02 ` Denis Excoffier 0 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-03-05 10:00 UTC (permalink / raw) To: cygwin On Mar 5 08:09, Denis Excoffier wrote: > On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote: > >> On Feb 8 11:22, Denis Excoffier wrote: > >> > On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: > >> > >> On Feb 8 10:08, Denis Excoffier wrote: > >> > >> > Result is: > >> > >> > > >> > >> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 1=DLL_LINK) is perhaps already occupied > >> > >> > 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 1=DLL_LINK) is perhaps already occupied > >> > >> > 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C0000 with type 2=DLL_LOAD) is perhaps already occupied > >> > >> > 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C0000 with type 2=DLL_LOAD) is perhaps already occupied > >> > >> Denis, can you please give the latest snapshot DLL a try in all > >> circumstances in which you saw the above kind of fork problems in > >> 1.7.10? I applied a patch which should now work out the differences > >> between linked and loaded DLLs better than before. > >> > % uname -a > CYGWIN_NT-5.1 edited 1.7.12s(0.260/5/3) 20120304 17:49:39 i686 Cygwin > % > > I am now unable to report any problem of that sort. I have compiled the > cygwin1.dll, the new gcc-4.7.0-rc-20120302, and several other > packages with no occurrence of such a message. Thanks for testing. Can you lease run this a while longer, just to be sure? > I've only to report that i observe some time to time the "something > failed for pid" message (see several instances below). "Win32 Error 5" > is ERROR_ACCESS_DENIED i suppose (in winerrors.h). I don't know > what we are expected to do with these. In addition, they do not seem > to hurt much. > [...] > 947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0: res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > 2 [main] sh 3360! _pinfo::dup_proc_pipe: something failed for pid 0: res 3360, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > 1345 [main] sh 3772! _pinfo::dup_proc_pipe: something failed for pid 0: res 3772, hProcess 0x6CC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > [...] Actually, I don't quite understand them. The pid is apparently not initialized yet, at the time the message occurs. The code in question tries to duplicate a pipe handle into another process and fails. But the process handle to the other has been created by this process, so it should have all rights to duplicate the handle. Hmm. What command were you running at the time? Maybe it is reproducible. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-05 10:00 ` Corinna Vinschen @ 2012-03-05 12:02 ` Denis Excoffier 2012-03-05 12:15 ` Corinna Vinschen 0 siblings, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-03-05 12:02 UTC (permalink / raw) To: cygwin On Mon, Mar 05, 2012 at 10:59:19AM +0100, Corinna Vinschen wrote: >> On Mar 5 08:09, Denis Excoffier wrote: >> > On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote: >> > >> Denis, can you please give the latest snapshot DLL a try in all >> > >> circumstances in which you saw the above kind of fork problems in >> > >> 1.7.10? I applied a patch which should now work out the differences >> > >> between linked and loaded DLLs better than before. >> > >> >> > >> > I am now unable to report any problem of that sort. I have compiled the >> > cygwin1.dll, the new gcc-4.7.0-rc-20120302, and several other >> > packages with no occurrence of such a message. >> >> Thanks for testing. Can you lease run this a while longer, just to >> be sure? I'll replace cygwin1.dll with the next snapshot. >> >> > I've only to report that i observe some time to time the "something >> > failed for pid" message (see several instances below). "Win32 Error 5" >> > is ERROR_ACCESS_DENIED i suppose (in winerrors.h). I don't know >> > what we are expected to do with these. In addition, they do not seem >> > to hurt much. >> > [...] >> > 947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0: res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 >> > 2 [main] sh 3360! _pinfo::dup_proc_pipe: something failed for pid 0: res 3360, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 >> > 1345 [main] sh 3772! _pinfo::dup_proc_pipe: something failed for pid 0: res 3772, hProcess 0x6CC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 >> > [...] >> >> Actually, I don't quite understand them. The pid is apparently not >> initialized yet, at the time the message occurs. The code in question >> tries to duplicate a pipe handle into another process and fails. But >> the process handle to the other has been created by this process, so it >> should have all rights to duplicate the handle. Hmm. What command >> were you running at the time? Maybe it is reproducible. You mean, may be it is debuggable? Please first apply the following, and provide me with further instrumentation in order that i can narrow down the problem when it occurs. *** winsup0/cygwin/pinfo.cc Wed Feb 15 15:46:18 2012 --- winsup/cygwin/pinfo.cc Mon Mar 5 12:53:30 2012 *************** *** 1001,1007 **** { wr_proc_pipe = orig_wr_proc_pipe; warn_printf ("something failed for pid %d: res %d, hProcess %p, wr_proc_pipe %p vs. %p, %E", ! res, pid, hProcess, wr_proc_pipe, orig_wr_proc_pipe); } else { --- 1001,1007 ---- { wr_proc_pipe = orig_wr_proc_pipe; warn_printf ("something failed for pid %d: res %d, hProcess %p, wr_proc_pipe %p vs. %p, %E", ! pid, res, hProcess, wr_proc_pipe, orig_wr_proc_pipe); } else { 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-05 12:02 ` Denis Excoffier @ 2012-03-05 12:15 ` Corinna Vinschen 2012-03-07 17:48 ` Corinna Vinschen 0 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-03-05 12:15 UTC (permalink / raw) To: cygwin On Mar 5 13:02, Denis Excoffier wrote: > On Mon, Mar 05, 2012 at 10:59:19AM +0100, Corinna Vinschen wrote: > >> On Mar 5 08:09, Denis Excoffier wrote: > >> > 947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0: res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > >> > 2 [main] sh 3360! _pinfo::dup_proc_pipe: something failed for pid 0: res 3360, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > >> > 1345 [main] sh 3772! _pinfo::dup_proc_pipe: something failed for pid 0: res 3772, hProcess 0x6CC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > >> > [...] > >> > >> Actually, I don't quite understand them. The pid is apparently not > >> initialized yet, at the time the message occurs. The code in question > >> tries to duplicate a pipe handle into another process and fails. But > >> the process handle to the other has been created by this process, so it > >> should have all rights to duplicate the handle. Hmm. What command > >> were you running at the time? Maybe it is reproducible. > You mean, may be it is debuggable? > > Please first apply the following, and provide me with further > instrumentation in order that i can narrow down the problem when it > occurs. > > *** winsup0/cygwin/pinfo.cc Wed Feb 15 15:46:18 2012 > --- winsup/cygwin/pinfo.cc Mon Mar 5 12:53:30 2012 > *************** > *** 1001,1007 **** > { > wr_proc_pipe = orig_wr_proc_pipe; > warn_printf ("something failed for pid %d: res %d, hProcess %p, wr_proc_pipe %p vs. %p, %E", > ! res, pid, hProcess, wr_proc_pipe, orig_wr_proc_pipe); > } > else > { > --- 1001,1007 ---- > { > wr_proc_pipe = orig_wr_proc_pipe; > warn_printf ("something failed for pid %d: res %d, hProcess %p, wr_proc_pipe %p vs. %p, %E", > ! pid, res, hProcess, wr_proc_pipe, orig_wr_proc_pipe); > } > else > { Thanks for catching! I applied this patch. So the pids are not wrong, after all. As for debugging, it would be helpful to have a command to reproduce it. I can't tell you off-hand what to hunt for. This is Chris' code, so he probably knows much better what to look for than I do. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-05 12:15 ` Corinna Vinschen @ 2012-03-07 17:48 ` Corinna Vinschen 2012-03-08 8:50 ` Denis Excoffier 0 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-03-07 17:48 UTC (permalink / raw) To: cygwin Hi Denis, On Mar 5 13:14, Corinna Vinschen wrote: > On Mar 5 13:02, Denis Excoffier wrote: > > On Mon, Mar 05, 2012 at 10:59:19AM +0100, Corinna Vinschen wrote: > > >> On Mar 5 08:09, Denis Excoffier wrote: > > >> > 947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0: res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > > >> > 2 [main] sh 3360! _pinfo::dup_proc_pipe: something failed for pid 0: res 3360, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > > >> > 1345 [main] sh 3772! _pinfo::dup_proc_pipe: something failed for pid 0: res 3772, hProcess 0x6CC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 > > >> > [...] > > >> > > >> Actually, I don't quite understand them. The pid is apparently not > > >> initialized yet, at the time the message occurs. The code in question > > >> tries to duplicate a pipe handle into another process and fails. But > > >> the process handle to the other has been created by this process, so it > > >> should have all rights to duplicate the handle. Hmm. What command > > >> were you running at the time? Maybe it is reproducible. > > You mean, may be it is debuggable? > > > > Please first apply the following, and provide me with further > > instrumentation in order that i can narrow down the problem when it > > occurs. > > > > *** winsup0/cygwin/pinfo.cc Wed Feb 15 15:46:18 2012 > > --- winsup/cygwin/pinfo.cc Mon Mar 5 12:53:30 2012 > > *************** > > *** 1001,1007 **** > > { > > wr_proc_pipe = orig_wr_proc_pipe; > > warn_printf ("something failed for pid %d: res %d, hProcess %p, wr_proc_pipe %p vs. %p, %E", > > ! res, pid, hProcess, wr_proc_pipe, orig_wr_proc_pipe); > > } > > else > > { > > --- 1001,1007 ---- > > { > > wr_proc_pipe = orig_wr_proc_pipe; > > warn_printf ("something failed for pid %d: res %d, hProcess %p, wr_proc_pipe %p vs. %p, %E", > > ! pid, res, hProcess, wr_proc_pipe, orig_wr_proc_pipe); > > } > > else > > { > > Thanks for catching! I applied this patch. So the pids are not wrong, > after all. As for debugging, it would be helpful to have a command to > reproduce it. I can't tell you off-hand what to hunt for. This is > Chris' code, so he probably knows much better what to look for than I do. can you please test this again using the latest developer snapshot or the current from CVS if you build Cygwin by yourself? It provides a bit more information to find the reason for the permission denied error in _pinfo::dup_proc_pipe. In theory, the user should have permissions to duplicate handles into every own process, if the handle has been opened with these permissions, so it's quite interesting to find the reason. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-07 17:48 ` Corinna Vinschen @ 2012-03-08 8:50 ` Denis Excoffier 2012-03-08 9:56 ` Corinna Vinschen 0 siblings, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-03-08 8:50 UTC (permalink / raw) To: cygwin On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote: >> Hi Denis, >> >> can you please test this again using the latest developer snapshot or >> the current from CVS if you build Cygwin by yourself? It provides a bit >> more information to find the reason for the permission denied error in >> _pinfo::dup_proc_pipe. Thank you cgf (the committer and snapshot maker at least). >> >> In theory, the user should have permissions to duplicate handles into >> every own process, if the handle has been opened with these permissions, >> so it's quite interesting to find the reason. >> After about 3 hours of exercising the new snapshot (and shaking it a little), i met the "something failed" instance only twice: 1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 0x764: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 0x768: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 I continue, of course. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-08 8:50 ` Denis Excoffier @ 2012-03-08 9:56 ` Corinna Vinschen 2012-03-09 15:48 ` Christopher Faylor 0 siblings, 1 reply; 51+ messages in thread From: Corinna Vinschen @ 2012-03-08 9:56 UTC (permalink / raw) To: cygwin On Mar 8 09:50, Denis Excoffier wrote: > On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote: > >> Hi Denis, > >> > >> can you please test this again using the latest developer snapshot or > >> the current from CVS if you build Cygwin by yourself? It provides a bit > >> more information to find the reason for the permission denied error in > >> _pinfo::dup_proc_pipe. > Thank you cgf (the committer and snapshot maker at least). > >> > >> In theory, the user should have permissions to duplicate handles into > >> every own process, if the handle has been opened with these permissions, > >> so it's quite interesting to find the reason. > >> > > After about 3 hours of exercising the new snapshot (and shaking it a > little), i met the "something failed" instance only twice: > > 1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 0x764: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 > 503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 0x768: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 > > I continue, of course. Thanks, I don't think it's necessary to try further. What this shows is that the process handle returned by the call to CreateProcess sometimes, for some reason, does not allow handle duplication. That's weird. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-08 9:56 ` Corinna Vinschen @ 2012-03-09 15:48 ` Christopher Faylor 2012-03-16 17:14 ` Christopher Faylor 0 siblings, 1 reply; 51+ messages in thread From: Christopher Faylor @ 2012-03-09 15:48 UTC (permalink / raw) To: cygwin On Thu, Mar 08, 2012 at 10:55:35AM +0100, Corinna Vinschen wrote: >On Mar 8 09:50, Denis Excoffier wrote: >> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote: >> >> Hi Denis, >> >> >> >> can you please test this again using the latest developer snapshot or >> >> the current from CVS if you build Cygwin by yourself? It provides a bit >> >> more information to find the reason for the permission denied error in >> >> _pinfo::dup_proc_pipe. >> Thank you cgf (the committer and snapshot maker at least). >> >> >> >> In theory, the user should have permissions to duplicate handles into >> >> every own process, if the handle has been opened with these permissions, >> >> so it's quite interesting to find the reason. >> >> >> >> After about 3 hours of exercising the new snapshot (and shaking it a >> little), i met the "something failed" instance only twice: >> >> 1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 0x764: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >> 503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 0x768: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >> >> I continue, of course. > >Thanks, I don't think it's necessary to try further. What this shows is >that the process handle returned by the call to CreateProcess sometimes, >for some reason, does not allow handle duplication. That's weird. I have a vague idea about why this is happening. I'll look into it within the next 48 hours. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-09 15:48 ` Christopher Faylor @ 2012-03-16 17:14 ` Christopher Faylor 2012-03-16 18:41 ` Denis Excoffier 2012-03-19 20:55 ` Christopher Faylor 0 siblings, 2 replies; 51+ messages in thread From: Christopher Faylor @ 2012-03-16 17:14 UTC (permalink / raw) To: cygwin On Fri, Mar 09, 2012 at 10:48:30AM -0500, Christopher Faylor wrote: >On Thu, Mar 08, 2012 at 10:55:35AM +0100, Corinna Vinschen wrote: >>On Mar 8 09:50, Denis Excoffier wrote: >>> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote: >>> >> Hi Denis, >>> >> >>> >> can you please test this again using the latest developer snapshot or >>> >> the current from CVS if you build Cygwin by yourself? It provides a bit >>> >> more information to find the reason for the permission denied error in >>> >> _pinfo::dup_proc_pipe. >>> Thank you cgf (the committer and snapshot maker at least). >>> >> >>> >> In theory, the user should have permissions to duplicate handles into >>> >> every own process, if the handle has been opened with these permissions, >>> >> so it's quite interesting to find the reason. >>> >> >>> >>> After about 3 hours of exercising the new snapshot (and shaking it a >>> little), i met the "something failed" instance only twice: >>> >>> 1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 0x764: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >>> 503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 0x768: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >>> >>> I continue, of course. >> >>Thanks, I don't think it's necessary to try further. What this shows is >>that the process handle returned by the call to CreateProcess sometimes, >>for some reason, does not allow handle duplication. That's weird. > >I have a vague idea about why this is happening. I'll look into it within >the next 48 hours. My vague idea about this proved to be incorrect. I did manage to make a royal mess of the exec synchronization code before I figured that out though so at least that's something. Denis, did you see this while running the STC in http://cygwin.com/ml/cygwin/2012-02/msg00187.html ? Also, I checked back through the archives but didn't see any cygcheck output from you. Maybe I just missed it but would you mind sending it here? To see if I could duplicate this, I created a STC which rapidly forked a bunch of processes which also execed themselves. I could never get this error to show up though. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-16 17:14 ` Christopher Faylor @ 2012-03-16 18:41 ` Denis Excoffier 2012-03-19 20:55 ` Christopher Faylor 1 sibling, 0 replies; 51+ messages in thread From: Denis Excoffier @ 2012-03-16 18:41 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 3158 bytes --] On 2012-03-16 18:14, Christopher Faylor wrote: > On Fri, Mar 09, 2012 at 10:48:30AM -0500, Christopher Faylor wrote: >> On Thu, Mar 08, 2012 at 10:55:35AM +0100, Corinna Vinschen wrote: >>> On Mar 8 09:50, Denis Excoffier wrote: >>>> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote: >>>>>> Hi Denis, >>>>>> >>>>>> can you please test this again using the latest developer snapshot or >>>>>> the current from CVS if you build Cygwin by yourself? It provides a bit >>>>>> more information to find the reason for the permission denied error in >>>>>> _pinfo::dup_proc_pipe. >>>> Thank you cgf (the committer and snapshot maker at least). >>>>>> >>>>>> In theory, the user should have permissions to duplicate handles into >>>>>> every own process, if the handle has been opened with these permissions, >>>>>> so it's quite interesting to find the reason. >>>>>> >>>> >>>> After about 3 hours of exercising the new snapshot (and shaking it a >>>> little), i met the "something failed" instance only twice: >>>> >>>> 1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 0x764: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >>>> 503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 0x768: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >>>> >>>> I continue, of course. >>> >>> Thanks, I don't think it's necessary to try further. What this shows is >>> that the process handle returned by the call to CreateProcess sometimes, >>> for some reason, does not allow handle duplication. That's weird. >> >> I have a vague idea about why this is happening. I'll look into it within >> the next 48 hours. > > My vague idea about this proved to be incorrect. I did manage to make a > royal mess of the exec synchronization code before I figured that out > though so at least that's something. > > Denis, did you see this while running the STC in > > http://cygwin.com/ml/cygwin/2012-02/msg00187.html > > ? No i didn't. This STC was another (probably independent, but much more important) problem, solved by Corinna in February. For the moment i could not find any reproducible scheme that leads to "process synchronization failed". However, a full night of various compilations (using make -j 3) produces about a dozen of such messages (using make with no -j produces no message, that's all what i know for the moment). > > Also, I checked back through the archives but didn't see any cygcheck > output from you. Maybe I just missed it but would you mind sending it > here? Included cygcheck.out and cygcheck.err (from last Tuesday). Other problems i still have not fully reported: - ldd produces "??? => ???" on some DLLs (/usr/bin/cygoctave-1.dll produces 6 such lines) - strace produces "too many environment variables" always - sometimes a process get frozen (not reproducible), if i kill it, the killing process also gets frozen Denis Excoffier. [-- Attachment #2: cygcheck.out --] [-- Type: application/octet-stream, Size: 319031 bytes --] [-- Attachment #3: Type: text/plain, Size: 1 bytes --] [-- Attachment #4: cygcheck.err --] [-- Type: application/octet-stream, Size: 94 bytes --] /usr/bin/cygrunsrv: warning: OpenService failed for 'TapiSrv': Win32 error 5 Accès refusé. [-- Attachment #5: Type: text/plain, Size: 3 bytes --] [-- Attachment #6: Type: text/plain, Size: 218 bytes --] -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: cygwin-1.7.10-1 fork - address space needed by ... already in use 2012-03-16 17:14 ` Christopher Faylor 2012-03-16 18:41 ` Denis Excoffier @ 2012-03-19 20:55 ` Christopher Faylor 2012-03-20 5:11 ` 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use) Christopher Faylor 1 sibling, 1 reply; 51+ messages in thread From: Christopher Faylor @ 2012-03-19 20:55 UTC (permalink / raw) To: cygwin On Fri, Mar 16, 2012 at 01:14:26PM -0400, Christopher Faylor wrote: >On Fri, Mar 09, 2012 at 10:48:30AM -0500, Christopher Faylor wrote: >>On Thu, Mar 08, 2012 at 10:55:35AM +0100, Corinna Vinschen wrote: >>>On Mar 8 09:50, Denis Excoffier wrote: >>>> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote: >>>> >> Hi Denis, >>>> >> >>>> >> can you please test this again using the latest developer snapshot or >>>> >> the current from CVS if you build Cygwin by yourself? It provides a bit >>>> >> more information to find the reason for the permission denied error in >>>> >> _pinfo::dup_proc_pipe. >>>> Thank you cgf (the committer and snapshot maker at least). >>>> >> >>>> >> In theory, the user should have permissions to duplicate handles into >>>> >> every own process, if the handle has been opened with these permissions, >>>> >> so it's quite interesting to find the reason. >>>> >> >>>> >>>> After about 3 hours of exercising the new snapshot (and shaking it a >>>> little), i met the "something failed" instance only twice: >>>> >>>> 1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 0x764: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >>>> 503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 0x768: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5 >>>> >>>> I continue, of course. >>> >>>Thanks, I don't think it's necessary to try further. What this shows is >>>that the process handle returned by the call to CreateProcess sometimes, >>>for some reason, does not allow handle duplication. That's weird. >> >>I have a vague idea about why this is happening. I'll look into it within >>the next 48 hours. > >My vague idea about this proved to be incorrect. I did manage to make a >royal mess of the exec synchronization code before I figured that out >though so at least that's something. > >Denis, did you see this while running the STC in > >http://cygwin.com/ml/cygwin/2012-02/msg00187.html > >? > >Also, I checked back through the archives but didn't see any cygcheck >output from you. Maybe I just missed it but would you mind sending it >here? > >To see if I could duplicate this, I created a STC which rapidly forked a >bunch of processes which also execed themselves. I could never get this >error to show up though. Thanks for the cygcheck output. I was never able to duplicate the problem so I rewrote the way this was handled. The error message is completely gone now. With luck you won't see anything like this now. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use) 2012-03-19 20:55 ` Christopher Faylor @ 2012-03-20 5:11 ` Christopher Faylor 2012-03-20 23:56 ` All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) Christopher Faylor 0 siblings, 1 reply; 51+ messages in thread From: Christopher Faylor @ 2012-03-20 5:11 UTC (permalink / raw) To: cygwin On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote: >[snip] >Thanks for the cygcheck output. > >I was never able to duplicate the problem so I rewrote the way this was >handled. The error message is completely gone now. > >With luck you won't see anything like this now. My change to fix this problem did something bad to process syncronization. I have the beginnings of a fix in my sandbox but I'm not quite ready to check anything in. In the meantime, I'd advise against using the 2012-03-19 snapshot. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-20 5:11 ` 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use) Christopher Faylor @ 2012-03-20 23:56 ` Christopher Faylor 2012-03-21 4:41 ` marco atzeri 2012-03-21 7:11 ` Denis Excoffier 0 siblings, 2 replies; 51+ messages in thread From: Christopher Faylor @ 2012-03-20 23:56 UTC (permalink / raw) To: cygwin On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote: >On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote: >>[snip] >>Thanks for the cygcheck output. >> >>I was never able to duplicate the problem so I rewrote the way this was >>handled. The error message is completely gone now. >> >>With luck you won't see anything like this now. > >My change to fix this problem did something bad to process >syncronization. I have the beginnings of a fix in my sandbox >but I'm not quite ready to check anything in. > >In the meantime, I'd advise against using the 2012-03-19 snapshot. The latest snapshot should now be ok. http://cygwin.com/snapshots/ 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-20 23:56 ` All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) Christopher Faylor @ 2012-03-21 4:41 ` marco atzeri 2012-03-21 5:44 ` marco atzeri 2012-03-21 7:11 ` Denis Excoffier 1 sibling, 1 reply; 51+ messages in thread From: marco atzeri @ 2012-03-21 4:41 UTC (permalink / raw) To: cygwin On 3/21/2012 12:56 AM, Christopher Faylor wrote: > On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote: >> On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote: >>> [snip] >>> Thanks for the cygcheck output. >>> >>> I was never able to duplicate the problem so I rewrote the way this was >>> handled. The error message is completely gone now. >>> >>> With luck you won't see anything like this now. >> >> My change to fix this problem did something bad to process >> syncronization. I have the beginnings of a fix in my sandbox >> but I'm not quite ready to check anything in. >> >> In the meantime, I'd advise against using the 2012-03-19 snapshot. > > The latest snapshot should now be ok. > > http://cygwin.com/snapshots/ > > cgf > unfortunately no dash+rebaseall shows: 0 [waitproc] dash 6868! proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 and the process never complete. $ uname -a CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.12s(0.260/5/3) 20120320 23:14:21 i686 Cygwin -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-21 4:41 ` marco atzeri @ 2012-03-21 5:44 ` marco atzeri 0 siblings, 0 replies; 51+ messages in thread From: marco atzeri @ 2012-03-21 5:44 UTC (permalink / raw) To: cygwin On 3/21/2012 5:41 AM, marco atzeri wrote: > On 3/21/2012 12:56 AM, Christopher Faylor wrote: >> On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote: >>> On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote: >>>> [snip] >>>> Thanks for the cygcheck output. >>>> >>>> I was never able to duplicate the problem so I rewrote the way this was >>>> handled. The error message is completely gone now. >>>> >>>> With luck you won't see anything like this now. >>> >>> My change to fix this problem did something bad to process >>> syncronization. I have the beginnings of a fix in my sandbox >>> but I'm not quite ready to check anything in. >>> >>> In the meantime, I'd advise against using the 2012-03-19 snapshot. >> >> The latest snapshot should now be ok. >> >> http://cygwin.com/snapshots/ >> >> cgf >> > > unfortunately no > dash+rebaseall shows: > > 0 [waitproc] dash 6868! proc_waiter: error on read of child wait pipe 0x0, > Win32 error 6 > > and the process never complete. > > > $ uname -a > CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.12s(0.260/5/3) 20120320 23:14:21 > i686 Cygwin > I guess I was to fast... $ uname -a CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.12s(0.260/5/3) 20120321 05:24:00 i686 Cygwin this seems fine -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-20 23:56 ` All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) Christopher Faylor 2012-03-21 4:41 ` marco atzeri @ 2012-03-21 7:11 ` Denis Excoffier 2012-03-22 4:38 ` Christopher Faylor 1 sibling, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-03-21 7:11 UTC (permalink / raw) To: cygwin On Tue, Mar 20, 2012 at 07:56:19PM -0400, Christopher Faylor wrote: >> On Tue, Mar 20, 2012 at 01:10:51AM -0400, Christopher Faylor wrote: >> >On Mon, Mar 19, 2012 at 04:54:33PM -0400, Christopher Faylor wrote: >> >>[snip] >> >>Thanks for the cygcheck output. >> >> >> >>I was never able to duplicate the problem so I rewrote the way this was >> >>handled. The error message is completely gone now. >> >> >> >>With luck you won't see anything like this now. >> > >> >My change to fix this problem did something bad to process >> >syncronization. I have the beginnings of a fix in my sandbox >> >but I'm not quite ready to check anything in. >> > >> >In the meantime, I'd advise against using the 2012-03-19 snapshot. >> >> The latest snapshot should now be ok. >> >> http://cygwin.com/snapshots/ >> The snapshot 20120321 05:29:25 UTC has still the following problems: 1) (most important for me): xinit does not launch I tried with both xorg-server 1.11.4 and 1.12.0 (TEST) with the same message: /usr/bin/xinit: giving up /usr/bin/xinit: unable to connect to X server: Connection refused /usr/bin/xinit: server error This occurs immediately after: (EE) AIGLX: No native OpenGL in modes with a root window (II) AIGLX: Loaded and initialized swrast (II) GLX: Initialized DRISWRAST GL provider for screen 0 and the following does not show up (compared with snapshot 20120314): winPointerWarpCursor - Discarding first warp: 696 497 (--) 5 mouse buttons found (--) Setting autorepeat to delay=500, rate=31 2) The /usr/bin/man program does not function properly. Under Cygwin.bat console (with "bash --login -i"): % man tr ... hit space a few times (5 times in my case) unless you obtain "(END)" then 'q' to exit the program. The /usr/bin/man exits but the prompt does not appear again and the shell is stuck. I had to return to snapshot 20120314, sorry. Best 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-21 7:11 ` Denis Excoffier @ 2012-03-22 4:38 ` Christopher Faylor 2012-03-22 6:57 ` Denis Excoffier 0 siblings, 1 reply; 51+ messages in thread From: Christopher Faylor @ 2012-03-22 4:38 UTC (permalink / raw) To: cygwin On Wed, Mar 21, 2012 at 08:10:46AM +0059, Denis Excoffier wrote: >The snapshot 20120321 05:29:25 UTC has still the following problems: The current snapshot should fix the hang issues. -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-22 4:38 ` Christopher Faylor @ 2012-03-22 6:57 ` Denis Excoffier 2012-03-22 13:29 ` Christopher Faylor 0 siblings, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-03-22 6:57 UTC (permalink / raw) To: cygwin On Thu, Mar 22, 2012 at 12:38:00AM -0400, Christopher Faylor wrote: >> On Wed, Mar 21, 2012 at 08:10:46AM +0059, Denis Excoffier wrote: >> >The snapshot 20120321 05:29:25 UTC has still the following problems: >> >> The current snapshot should fix the hang issues. >> I'm balancing between reporting quickly and reporting too quickly, but indeed, using snapshot that itself indicates '20120321 15:56:37': - 'exec /usr/bin/tcsh' works with no waitproc message - 'man tr' works with no hang - xinit works - build of cygwin-src-20120321.tar.bz2 is ok - 'many compiles during all night' work with no special message (i grepped '[[]main[]]' and '[[]waitproc[]]' in all stdout's and stderr's, no result) Before, it would have produced about 10 'process synchronization failed' messages... Of course, i use this snapshot now, perhaps it's time for 1.7.12? I'll nevertheless try the following in the next hours: - compilation of GCC 4.7.0-RC-20120314 (or plain 4.7.0 if available?) - in tcsh: several concurrent combinations of 'make -j 3', 'make', fg, Control-Z, bg, which has shown to make tcsh to expose '(badjob)' and the PC to hang sometimes. The Makefile is as follows: % cat Makefile | tr '\011' 'é' SHELL:=/bin/sh X:=${shell seq 10001 11000} Y:=${patsubst %,c%,${X}} all: ${Y} c%: é@for once in once; do \ # printf "{$@}"; \ Z=`date | sed -e 's|2012|2011|g'`; \ Z=`ls /C* | tr C D`; \ # echo $${Z}; \ done % I feel that a nice job has been done. Thank you. Regards, Denis Excoffier. P.S. What to do next? cgf has already received so many gold stars... -- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-22 6:57 ` Denis Excoffier @ 2012-03-22 13:29 ` Christopher Faylor 2012-03-22 14:38 ` Denis Excoffier ` (2 more replies) 0 siblings, 3 replies; 51+ messages in thread From: Christopher Faylor @ 2012-03-22 13:29 UTC (permalink / raw) To: cygwin On Thu, Mar 22, 2012 at 07:56:32AM +0100, Denis Excoffier wrote: >- in tcsh: several concurrent combinations of 'make -j 3', 'make', > fg, Control-Z, bg, which has shown to make tcsh to expose '(badjob)' > and the PC to hang sometimes. Are you saying that there *is* a problem with the current snapshot? Or that you saw a problem with this in 1.7.11 or that you have always seen a problem with this? >P.S. What to do next? cgf has already received so many gold stars... I don't need a gold star. Just doing my job... 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-22 13:29 ` Christopher Faylor @ 2012-03-22 14:38 ` Denis Excoffier 2012-03-22 15:13 ` Christopher Faylor 2012-03-22 15:33 ` Karl M 2012-03-22 15:36 ` Karl M 2 siblings, 1 reply; 51+ messages in thread From: Denis Excoffier @ 2012-03-22 14:38 UTC (permalink / raw) To: cygwin On Thu, Mar 22, 2012 at 09:29:38AM -0400, Christopher Faylor wrote: >> On Thu, Mar 22, 2012@07:56:32AM +0100, Denis Excoffier wrote: >> >- in tcsh: several concurrent combinations of 'make -j 3', 'make', >> > fg, Control-Z, bg, which has shown to make tcsh to expose '(badjob)' >> > and the PC to hang sometimes. >> >> Are you saying that there *is* a problem with the current snapshot? Or >> that you saw a problem with this in 1.7.11 or that you have always seen >> a problem with this? I'm saying that i'll try this sort of thing, since this failed with the snapshot 20120314. I tried this morning, and definitely yes, the '(badjob)' is rather easy to obtain, but now i know that this is a (well known) tcsh problem (see BUGS in the tcsh distribution), and has nothing to do with cygwin1.dll. When you finally kill the process that tcsh has lost, everything returns in order. I also compiled GCC 4.7.0 successfully with no message. In any case, with this snapshot 20120321 16h UTC, i was not able to make the PC hang (i tried it). In my opinion this is the best 1.7 we have ever had. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-22 14:38 ` Denis Excoffier @ 2012-03-22 15:13 ` Christopher Faylor 0 siblings, 0 replies; 51+ messages in thread From: Christopher Faylor @ 2012-03-22 15:13 UTC (permalink / raw) To: cygwin On Thu, Mar 22, 2012 at 03:37:32PM +0100, Denis Excoffier wrote: >On Thu, Mar 22, 2012 at 09:29:38AM -0400, Christopher Faylor wrote: >>> On Thu, Mar 22, 2012@07:56:32AM +0100, Denis Excoffier wrote: >>> >- in tcsh: several concurrent combinations of 'make -j 3', 'make', >>> > fg, Control-Z, bg, which has shown to make tcsh to expose '(badjob)' >>> > and the PC to hang sometimes. >>> >>> Are you saying that there *is* a problem with the current snapshot? Or >>> that you saw a problem with this in 1.7.11 or that you have always seen >>> a problem with this? >I'm saying that i'll try this sort of thing, since this failed >with the snapshot 20120314. I tried this morning, and definitely yes, >the '(badjob)' is rather easy to obtain, but now i know that this is >a (well known) tcsh problem (see BUGS in the tcsh distribution), and >has nothing to do with cygwin1.dll. When you finally kill the process >that tcsh has lost, everything returns in order. > >I also compiled GCC 4.7.0 successfully with no message. > >In any case, with this snapshot 20120321 16h UTC, i was not able to >make the PC hang (i tried it). In my opinion this is the best 1.7 we >have ever had. Thanks for confirming and thanks for keeping the reports coming. I don't think I mentioned that *I think* that my recent changes should have made cygwin a little faster since I removed some synchronization points which might have caused occasional stalls in process creation. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* RE: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-22 13:29 ` Christopher Faylor 2012-03-22 14:38 ` Denis Excoffier @ 2012-03-22 15:33 ` Karl M 2012-03-22 15:36 ` Karl M 2 siblings, 0 replies; 51+ messages in thread From: Karl M @ 2012-03-22 15:33 UTC (permalink / raw) To: cygwin >P.S. What to do next? cgf has already received so many gold stars... I don't need a gold star. Just doing my job... ^ Ma'am 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* RE: All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) 2012-03-22 13:29 ` Christopher Faylor 2012-03-22 14:38 ` Denis Excoffier 2012-03-22 15:33 ` Karl M @ 2012-03-22 15:36 ` Karl M 2 siblings, 0 replies; 51+ messages in thread From: Karl M @ 2012-03-22 15:36 UTC (permalink / raw) To: cygwin >P.S. What to do next? cgf has already received so many gold stars... I don't need a gold star. Just doing my job Ma'am...He tips his hat and walkes off into the sunset and the music starts to play. 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2012-03-22 15:36 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-07 15:00 cygwin-1.7.10-1 fork - address space needed by ... already in use Scott M. Ballew 2012-02-07 15:44 ` Denis Excoffier 2012-02-07 16:15 ` Corinna Vinschen 2012-02-07 16:47 ` Ryan Johnson 2012-02-07 22:48 ` Denis Excoffier 2012-02-08 9:03 ` Corinna Vinschen 2012-02-08 9:08 ` Denis Excoffier 2012-02-08 9:27 ` Corinna Vinschen 2012-02-08 10:23 ` Denis Excoffier 2012-02-08 12:33 ` Earnie Boyd 2012-02-08 13:00 ` Corinna Vinschen 2012-02-08 13:35 ` Corinna Vinschen 2012-02-08 14:25 ` Heiko Elger 2012-02-08 14:37 ` Corinna Vinschen 2012-03-04 17:23 ` Corinna Vinschen 2012-02-08 14:55 ` Denis Excoffier 2012-02-08 15:06 ` Heiko Elger 2012-02-08 15:35 ` Denis Excoffier 2012-02-08 15:16 ` Corinna Vinschen 2012-02-09 11:07 ` Corinna Vinschen 2012-02-09 13:40 ` Denis Excoffier 2012-02-09 14:44 ` Denis Excoffier 2012-02-09 14:44 ` Corinna Vinschen 2012-02-10 12:35 ` Andrey Repin 2012-02-13 13:48 ` Scott M. Ballew 2012-02-23 16:30 ` Richard Gribble 2012-02-23 17:23 ` Corinna Vinschen 2012-03-04 17:22 ` Corinna Vinschen 2012-03-05 7:09 ` Denis Excoffier 2012-03-05 10:00 ` Corinna Vinschen 2012-03-05 12:02 ` Denis Excoffier 2012-03-05 12:15 ` Corinna Vinschen 2012-03-07 17:48 ` Corinna Vinschen 2012-03-08 8:50 ` Denis Excoffier 2012-03-08 9:56 ` Corinna Vinschen 2012-03-09 15:48 ` Christopher Faylor 2012-03-16 17:14 ` Christopher Faylor 2012-03-16 18:41 ` Denis Excoffier 2012-03-19 20:55 ` Christopher Faylor 2012-03-20 5:11 ` 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use) Christopher Faylor 2012-03-20 23:56 ` All clear (was Re: 2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)) Christopher Faylor 2012-03-21 4:41 ` marco atzeri 2012-03-21 5:44 ` marco atzeri 2012-03-21 7:11 ` Denis Excoffier 2012-03-22 4:38 ` Christopher Faylor 2012-03-22 6:57 ` Denis Excoffier 2012-03-22 13:29 ` Christopher Faylor 2012-03-22 14:38 ` Denis Excoffier 2012-03-22 15:13 ` Christopher Faylor 2012-03-22 15:33 ` Karl M 2012-03-22 15:36 ` Karl M
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).