This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: child (xterm) fork failure as it loads to different address
- From: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- To: cygwin at cygwin dot com
- Date: Mon, 29 Jul 2013 09:35:53 -0400
- Subject: Re: child (xterm) fork failure as it loads to different address
- References: <CANeJNHrjkr4v_jP3HRbpsDGW5LJOZKjA3Z2r92HAaf0c3ZU4sQ at mail dot gmail dot com> <51F65369 dot 9020001 at gmail dot com> <CANeJNHrZdry8r0hFU-+3AhCocL9TDU4Mr-vWL8xmBn228aSWWg at mail dot gmail dot com>
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