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