X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Wed, 8 Feb 2012 10:02:23 +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: <20120208090223.GC25129@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <33279157 DOT post AT talk DOT nabble DOT com> <20120207154359 DOT GA2952 AT qp9482> <20120207161428 DOT GB12159 AT calimero DOT vinschen DOT de> <4F31559B DOT 6060600 AT cs DOT utoronto DOT ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 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//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