* Re: child (xterm) fork failure as it loads to different address
2013-07-29 13:43 ` Ryan Johnson
@ 2013-07-29 13:48 ` Corinna Vinschen
2013-07-29 14:17 ` Ariel Burbaickij
2013-07-29 14:33 ` Ariel Burbaickij
2 siblings, 0 replies; 7+ messages in thread
From: Corinna Vinschen @ 2013-07-29 13:48 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: child (xterm) fork failure as it loads to different address
2013-07-29 13:43 ` Ryan Johnson
2013-07-29 13:48 ` Corinna Vinschen
@ 2013-07-29 14:17 ` Ariel Burbaickij
2013-07-29 14:33 ` Ariel Burbaickij
2 siblings, 0 replies; 7+ messages in thread
From: Ariel Burbaickij @ 2013-07-29 14:17 UTC (permalink / raw)
To: cygwin
>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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: child (xterm) fork failure as it loads to different address
2013-07-29 13:43 ` Ryan Johnson
2013-07-29 13:48 ` Corinna Vinschen
2013-07-29 14:17 ` Ariel Burbaickij
@ 2013-07-29 14:33 ` Ariel Burbaickij
2 siblings, 0 replies; 7+ messages in thread
From: Ariel Burbaickij @ 2013-07-29 14:33 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread