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 <corinna-cygwin AT cygwin DOT com>
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> <B0ED7173-1AC3-4B4E-8B79-3A9B22652684 AT Denis-Excoffier DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <B0ED7173-1AC3-4B4E-8B79-3A9B22652684@Denis-Excoffier.org>
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: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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/<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