X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4D74F565.6000105@ece.cmu.edu>
Date: Mon, 07 Mar 2011 10:10:29 -0500
From: Ryan Johnson <ryanjohn AT ece DOT cmu DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: Debugging help for fork failure: resource temporarily unavailable
References: <4D72B5F2 DOT 3090802 AT ece DOT cmu DOT edu>
In-Reply-To: <4D72B5F2.3090802@ece.cmu.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 2:59 PM, Ryan Johnson wrote:
> I'm hitting the oh-so-delightful fork failures when trying to compile 
> a cross-compiler toolchain, which is a pain because one fork failure 
> makes crosstool-ng start over. I've rebased, I've been over the BLODA 
> (Windows Defender slipped in even after I rejected the download), and 
> while they definitely helped there's likely to be at least one fork 
> failure while compiling a big project like glibc.
>
> So, now comes my plea (I don't know enough about cygwin to do this 
> myself). It seems like the usual culprit -- dll injection in the child 
> at an address that the parent already used -- could easily be 
> diagnosed by the code which notices and aborts the fork: given two 
> dlls which want to use the same address in the child process, the one 
> at a different address in the parent is probably to blame. Fingering 
> this offending DLL, either as part of the fork failure message or in a 
> log file of some sort, would make it infinitely easier for users to 
> diagnose the problem, and would also give a much clearer idea of what 
> really went wrong (we could order the BLODA by how often each app 
> causes headaches, for example).
Actually, a follow-up question: what is the difference between the fork 
(e.g. resource unavailable) failures vs. the errors about 'failed to 
remap dll ...' ? Looking at the code in dll_init.cc, if failure to remap 
a dll were really the source of fork failing, the error message should 
say so. Is there some other issue due to BLODA that also causes forks to 
fail?

Also, how does the (new?) peflagsall script interact with dll injection? 
It sounds like it's supposed to fix dll remapping problems on machines 
which support ASLR...

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