Message-ID: <4D72B5F2.3090802@ece.cmu.edu>
Date: Sat, 05 Mar 2011 17:15:14 -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.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Debugging help for fork failure: resource temporarily unavailable
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Hi all,

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

Might it be possible to do an LD_PRELOAD of some sort which hooks into 
fork() at the critical moment and prints the differences between 
/proc/$parent/maps and /proc/$child/maps? The code doesn't even need to 
be efficient; it just needs to be able to run when whatever internal 
helper of fork() returns an error but before the nascent child process 
is terminated.

If there exists such a convenient instrumentation point, I might be up 
to the task of exploiting it, but I wouldn't know where to start.

Thoughts? Ideas?
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