child (xterm) fork failure as it loads to different address

child (xterm) fork failure as it loads to different address

[Ariel Burbaickij]

Hello group,
I have a fresh installation of cygwin/ (cygcheck returns following for
cygwin1.dll: cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0
ts=2013-07-22 16:06)/cygwin-X (1.14.2-1 built 2013-07-08)  and
following happens:
upon attempt to execute startxwin.exe  get following error, while
startxwin attempt to execute xterm:

 xterm 5508 child_info_fork::abort: C:\nobackup\cygwin\bin\cygz.dll:
Loaded to different address: parent(0x320000) != child(0x3B0000)
xterm: Error 29, errno 11: Resource temporarily unavailable
Reason: spawn: fork() failed


while it is clear what happens, what is not clear is how to resolve
it, so that it does not happen anymore?

/wbr
Ariel Burbaickij

--
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: child (xterm) fork failure as it loads to different address

[marco atzeri]

Il 7/29/2013 10:10 AM, Ariel Burbaickij ha scritto:
> Hello group,
> I have a fresh installation of cygwin/ (cygcheck returns following for
> cygwin1.dll: cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0
> ts=2013-07-22 16:06)/cygwin-X (1.14.2-1 built 2013-07-08)  and
> following happens:
> upon attempt to execute startxwin.exe  get following error, while
> startxwin attempt to execute xterm:
>
>   xterm 5508 child_info_fork::abort: C:\nobackup\cygwin\bin\cygz.dll:
> Loaded to different address: parent(0x320000) != child(0x3B0000)
> xterm: Error 29, errno 11: Resource temporarily unavailable
> Reason: spawn: fork() failed
>
>
> while it is clear what happens, what is not clear is how to resolve
> it, so that it does not happen anymore?

http://cygwin.com/faq.html#faq.using.fixing-fork-failures

>
> /wbr
> Ariel Burbaickij
>
> --

otherwise, follow the guideline:
> Problem reports:       http://cygwin.com/problems.html



--
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: child (xterm) fork failure as it loads to different address

[Ariel Burbaickij]

OK, thank, you, so usual suspects. Now, removing, antivirus and stuff
will not be possible in this particular environment but adjustments in
the configuration are well possible, provided I will be able to prove
to administrators that troubles, indeed, stem from antivirus and co.
Now, I see in the FAQ in 4.42 section that these troubles were traced
and attributed to antiviri programs. Any more details about how they
were traced exactly, so that I can re-trace them too and provide a
proof, if needed? Now, this is for one thing. Another one, is the
possibility to run Windows 7 (in my case) or any Windows  OS, down to
and including NT in POSIX-compatible "mode". Is this step expected to
solve or at least alleviate all or at least some the troubles about
the square peg of fork() into the round whole of Windows?

On Mon, Jul 29, 2013 at 1:35 PM, marco atzeri <marco.atzeri@gmail.com> wrote:
> Il 7/29/2013 10:10 AM, Ariel Burbaickij ha scritto:
>
>> Hello group,
>> I have a fresh installation of cygwin/ (cygcheck returns following for
>> cygwin1.dll: cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0
>> ts=2013-07-22 16:06)/cygwin-X (1.14.2-1 built 2013-07-08)  and
>> following happens:
>> upon attempt to execute startxwin.exe  get following error, while
>> startxwin attempt to execute xterm:
>>
>>   xterm 5508 child_info_fork::abort: C:\nobackup\cygwin\bin\cygz.dll:
>> Loaded to different address: parent(0x320000) != child(0x3B0000)
>> xterm: Error 29, errno 11: Resource temporarily unavailable
>> Reason: spawn: fork() failed
>>
>>
>> while it is clear what happens, what is not clear is how to resolve
>> it, so that it does not happen anymore?
>
>
> http://cygwin.com/faq.html#faq.using.fixing-fork-failures
>
>>
>> /wbr
>> Ariel Burbaickij
>>
>> --
>
>
> otherwise, follow the guideline:
>>
>> Problem reports:       http://cygwin.com/problems.html
>
>
>
>
> --
> 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: child (xterm) fork failure as it loads to different address

[Ryan Johnson]

http://cygwin.com/acronyms/#TOFU

On 29/07/2013 8:15 AM, Ariel Burbaickij wrote:
> OK, thank, you, so usual suspects. Now, removing, antivirus and stuff
> will not be possible in this particular environment but adjustments in
> the configuration are well possible, provided I will be able to prove
> to administrators that troubles, indeed, stem from antivirus and co.
> Now, I see in the FAQ in 4.42 section that these troubles were traced
> and attributed to antiviri programs. Any more details about how they
> were traced exactly, so that I can re-trace them too and provide a
> proof, if needed?
The proof usually goes something like this:

1. People report fork() failures on the list, and a correlation is noted 
between those failures and presence of app/antivirus X.
2. It is confirmed (or at least considered highly probable) that X 
performs dll injection, the root cause of these sorts of fork() failures.
3. Somebody tries disabling/removing X and the fork() failures go away.
4. X gets added to BLODA and reports of fork() failures, not 
attributable to X, disappear from the list.

Eventually the process repeats when Y appears.

You could also try enabling BLODA detection [1] and see what turns up, 
or run the NirSoft DLL injection detector [2].

[1] http://cygwin.com/ml/cygwin/2012-02/msg00797.html
[2] http://www.nirsoft.net/utils/injected_dll.html

> Now, this is for one thing. Another one, is the
> possibility to run Windows 7 (in my case) or any Windows  OS, down to
> and including NT in POSIX-compatible "mode".
 From www.cygwin.com:
> The Cygwin DLL currently works with all recent, commercially released 
> x86 32 bit and 64 bit versions of Windows, starting with Windows XP SP3.
So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP 
SP1/SP2. But if your admins are really so worried about viruses, they 
won't let you run those ancient operating systems anyway, because MS no 
longer pushes security patches for them.

Given that you seem to have your choice of OS, though, you might try 
64-bit cygwin. The sheer amount of address space that becomes available, 
plus some careful design decisions for placement of cygwin-related dlls 
in that space, reduces the risk of fork failures considerably.

I don't think anybody has reported a fork failure on cygwin64 yet (knock 
on wood). I recently migrated to 64-bit cygwin with a new Win7/64 
install myself, and so far have not had to disable Windows Defender; the 
latter was a recurring source of trouble for my previous 32-bit cygwin 
install on Win7/64.

If you can't get cygwin64 running, you may be able to convince your 
admins to whitelist cygwin apps with the AV solution; that has a small 
chance of stopping the dll injection and allowing fork() to succeed. 
Don't get your hopes up, though: most AV leave the dll injection in 
place even when completely disabled system-wide, and just tell the dlls 
not to do anything (other than stepping on cygwin's toes, of course).

> Is this step expected to
> solve or at least alleviate all or at least some the troubles about
> the square peg of fork() into the round whole of Windows?
cygwin64 may do that... downgrading your OS will not.

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: child (xterm) fork failure as it loads to different address

[Corinna Vinschen]

On Jul 29 09:35, Ryan Johnson wrote:
> http://cygwin.com/acronyms/#TOFU
> 
> On 29/07/2013 8:15 AM, Ariel Burbaickij wrote:
> >OK, thank, you, so usual suspects. Now, removing, antivirus and stuff
> >will not be possible in this particular environment but adjustments in
> >the configuration are well possible, provided I will be able to prove
> >to administrators that troubles, indeed, stem from antivirus and co.
> >Now, I see in the FAQ in 4.42 section that these troubles were traced
> >and attributed to antiviri programs. Any more details about how they
> >were traced exactly, so that I can re-trace them too and provide a
> >proof, if needed?
> The proof usually goes something like this:
> 
> 1. People report fork() failures on the list, and a correlation is
> noted between those failures and presence of app/antivirus X.
> 2. It is confirmed (or at least considered highly probable) that X
> performs dll injection, the root cause of these sorts of fork()
> failures.
> 3. Somebody tries disabling/removing X and the fork() failures go away.
> 4. X gets added to BLODA and reports of fork() failures, not
> attributable to X, disappear from the list.
> 
> Eventually the process repeats when Y appears.

There's no Y.  The successor of X is allegedly called Wayland.


<duck>
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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: child (xterm) fork failure as it loads to different address

[Ariel Burbaickij]

>So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP SP1/SP2. But if your admins are really >so worried about viruses, they won't let you run those ancient operating systems anyway, because MS no longer >pushes security patches for them.

You misread, I am afraid. I am running Windows 7 here. Question is: Is
it expected that turning on POSIX-compatibility mode (possibly with
downloading of utilities for UNIX subsystem)  should help here or not?


Yes, let me try cygwin64 after I am done with rebasing, provided it is
still necessary, of course :-)

On Mon, Jul 29, 2013 at 3:35 PM, Ryan Johnson
<ryan.johnson@cs.utoronto.ca> wrote:
> http://cygwin.com/acronyms/#TOFU
>
>
> On 29/07/2013 8:15 AM, Ariel Burbaickij wrote:
>>
>> OK, thank, you, so usual suspects. Now, removing, antivirus and stuff
>> will not be possible in this particular environment but adjustments in
>> the configuration are well possible, provided I will be able to prove
>> to administrators that troubles, indeed, stem from antivirus and co.
>> Now, I see in the FAQ in 4.42 section that these troubles were traced
>> and attributed to antiviri programs. Any more details about how they
>> were traced exactly, so that I can re-trace them too and provide a
>> proof, if needed?
>
> The proof usually goes something like this:
>
> 1. People report fork() failures on the list, and a correlation is noted
> between those failures and presence of app/antivirus X.
> 2. It is confirmed (or at least considered highly probable) that X performs
> dll injection, the root cause of these sorts of fork() failures.
> 3. Somebody tries disabling/removing X and the fork() failures go away.
> 4. X gets added to BLODA and reports of fork() failures, not attributable to
> X, disappear from the list.
>
> Eventually the process repeats when Y appears.
>
> You could also try enabling BLODA detection [1] and see what turns up, or
> run the NirSoft DLL injection detector [2].
>
> [1] http://cygwin.com/ml/cygwin/2012-02/msg00797.html
> [2] http://www.nirsoft.net/utils/injected_dll.html
>
>
>> Now, this is for one thing. Another one, is the
>> possibility to run Windows 7 (in my case) or any Windows  OS, down to
>> and including NT in POSIX-compatible "mode".
>
> From www.cygwin.com:
>>
>> The Cygwin DLL currently works with all recent, commercially released x86
>> 32 bit and 64 bit versions of Windows, starting with Windows XP SP3.
>
> So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP
> SP1/SP2. But if your admins are really so worried about viruses, they won't
> let you run those ancient operating systems anyway, because MS no longer
> pushes security patches for them.
>
> Given that you seem to have your choice of OS, though, you might try 64-bit
> cygwin. The sheer amount of address space that becomes available, plus some
> careful design decisions for placement of cygwin-related dlls in that space,
> reduces the risk of fork failures considerably.
>
> I don't think anybody has reported a fork failure on cygwin64 yet (knock on
> wood). I recently migrated to 64-bit cygwin with a new Win7/64 install
> myself, and so far have not had to disable Windows Defender; the latter was
> a recurring source of trouble for my previous 32-bit cygwin install on
> Win7/64.
>
> If you can't get cygwin64 running, you may be able to convince your admins
> to whitelist cygwin apps with the AV solution; that has a small chance of
> stopping the dll injection and allowing fork() to succeed. Don't get your
> hopes up, though: most AV leave the dll injection in place even when
> completely disabled system-wide, and just tell the dlls not to do anything
> (other than stepping on cygwin's toes, of course).
>
>
>> Is this step expected to
>> solve or at least alleviate all or at least some the troubles about
>> the square peg of fork() into the round whole of Windows?
>
> cygwin64 may do that... downgrading your OS will not.
>
> 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
>

--
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: child (xterm) fork failure as it loads to different address

[Ariel Burbaickij]

OK, for the record: looks like rebasing did help quite a bit here.

/wbr
Ariel Burbaickij

On Mon, Jul 29, 2013 at 3:35 PM, Ryan Johnson
<ryan.johnson@cs.utoronto.ca> wrote:
> http://cygwin.com/acronyms/#TOFU
>
>
> On 29/07/2013 8:15 AM, Ariel Burbaickij wrote:
>>
>> OK, thank, you, so usual suspects. Now, removing, antivirus and stuff
>> will not be possible in this particular environment but adjustments in
>> the configuration are well possible, provided I will be able to prove
>> to administrators that troubles, indeed, stem from antivirus and co.
>> Now, I see in the FAQ in 4.42 section that these troubles were traced
>> and attributed to antiviri programs. Any more details about how they
>> were traced exactly, so that I can re-trace them too and provide a
>> proof, if needed?
>
> The proof usually goes something like this:
>
> 1. People report fork() failures on the list, and a correlation is noted
> between those failures and presence of app/antivirus X.
> 2. It is confirmed (or at least considered highly probable) that X performs
> dll injection, the root cause of these sorts of fork() failures.
> 3. Somebody tries disabling/removing X and the fork() failures go away.
> 4. X gets added to BLODA and reports of fork() failures, not attributable to
> X, disappear from the list.
>
> Eventually the process repeats when Y appears.
>
> You could also try enabling BLODA detection [1] and see what turns up, or
> run the NirSoft DLL injection detector [2].
>
> [1] http://cygwin.com/ml/cygwin/2012-02/msg00797.html
> [2] http://www.nirsoft.net/utils/injected_dll.html
>
>
>> Now, this is for one thing. Another one, is the
>> possibility to run Windows 7 (in my case) or any Windows  OS, down to
>> and including NT in POSIX-compatible "mode".
>
> From www.cygwin.com:
>>
>> The Cygwin DLL currently works with all recent, commercially released x86
>> 32 bit and 64 bit versions of Windows, starting with Windows XP SP3.
>
> So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP
> SP1/SP2. But if your admins are really so worried about viruses, they won't
> let you run those ancient operating systems anyway, because MS no longer
> pushes security patches for them.
>
> Given that you seem to have your choice of OS, though, you might try 64-bit
> cygwin. The sheer amount of address space that becomes available, plus some
> careful design decisions for placement of cygwin-related dlls in that space,
> reduces the risk of fork failures considerably.
>
> I don't think anybody has reported a fork failure on cygwin64 yet (knock on
> wood). I recently migrated to 64-bit cygwin with a new Win7/64 install
> myself, and so far have not had to disable Windows Defender; the latter was
> a recurring source of trouble for my previous 32-bit cygwin install on
> Win7/64.
>
> If you can't get cygwin64 running, you may be able to convince your admins
> to whitelist cygwin apps with the AV solution; that has a small chance of
> stopping the dll injection and allowing fork() to succeed. Don't get your
> hopes up, though: most AV leave the dll injection in place even when
> completely disabled system-wide, and just tell the dlls not to do anything
> (other than stepping on cygwin's toes, of course).
>
>
>> Is this step expected to
>> solve or at least alleviate all or at least some the troubles about
>> the square peg of fork() into the round whole of Windows?
>
> cygwin64 may do that... downgrading your OS will not.
>
> 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
>

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