cygwin-1.7.10-1 fork - address space needed by ... already in use

cygwin-1.7.10-1 fork - address space needed by ... already in use

[Scott M. Ballew]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Ryan Johnson]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Earnie Boyd]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Heiko Elger]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Heiko Elger]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

[-- 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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Andrey Repin]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Scott M. Ballew]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Richard Gribble]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Christopher Faylor]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Christopher Faylor]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

[-- 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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Christopher Faylor]

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

2012-03-19 snapshot problematic (was Re: cygwin-1.7.10-1 fork - address space needed by ... already in use)

[Christopher Faylor]

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

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]

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

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))

[marco atzeri]

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

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))

[marco atzeri]

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

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))

[Denis Excoffier]

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

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))

[Christopher Faylor]

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

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))

[Denis Excoffier]

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

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))

[Christopher Faylor]

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

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))

[Denis Excoffier]

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

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))

[Christopher Faylor]

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

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))

[Karl M]

>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

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))

[Karl M]

 
>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