X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 7 Feb 2012 17:14:28 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: cygwin-1.7.10-1 fork - address space needed by ... already in use Message-ID: <20120207161428.GB12159@calimero.vinschen.de> Mail-Followup-To: cygwin AT cygwin DOT com References: <33279157 DOT post AT talk DOT nabble DOT com> <20120207154359 DOT GA2952 AT qp9482> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120207154359.GA2952@qp9482> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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//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