X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; q=dns; s=default; b=a/ sD3ZGx2XaTNR237osuhlPKsBKa/S5CNs6YT62KmWNJhm+ruX4VnW6i30/boRDACr HhBRvWZkcdtUx8yCaJl3RuFPVLQPyvLzJkckMkikfAkR1XG4UGrL/iiPTtKy4c5u T/a1/cigE7C5K2U6GnA4jHKe3jeoT0gPJfzVatZWk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; s=default; bh=/C3pLz8H KNWr5xyUxNXbB7D06gg=; b=iBPUgqMZHDeX/hPn/5Zb2i+vFoloi3IK09XC0llu 15Nkh4d6SrIGLB+nyT7sIEmovnm/Isa1J5a0EV0bUYMz/+DGq+BD0/clnuE9TgCX gIE1kBIcqbCMmjuos1sbTZXSYTsHH4hW11ch9oATyXmRKOz3htuO6a9rhj7wfRBx vvE= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 MIME-Version: 1.0 X-Received: by 10.52.177.6 with SMTP id cm6mr21709393vdc.0.1375105702605; Mon, 29 Jul 2013 06:48:22 -0700 (PDT) In-Reply-To: <51F66FB9.6000802@cs.utoronto.ca> References: <51F65369 DOT 9020001 AT gmail DOT com> <51F66FB9 DOT 6000802 AT cs DOT utoronto DOT ca> Date: Mon, 29 Jul 2013 15:48:22 +0200 Message-ID: Subject: Re: child (xterm) fork failure as it loads to different address From: Ariel Burbaickij To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=ISO-8859-1 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 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