X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=0.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW
X-Spam-Check-By:	sourceware.org
Message-ID:	<4D739D0F.5060102@gmail.com>
Date:	Sun, 06 Mar 2011 09:41:19 -0500
From:	chm <devel DOT chm DOT 01 AT gmail DOT com>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version:	1.0
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
CC:	Ryan Johnson <ryanjohn AT ece DOT cmu DOT edu>
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>
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).

I would like to second the motion.  This additional
information would be a help in diagnosing/discussing
and possible repairing the problem.  My situation
involves many perl modules and the current solution
is to rebaseall, peflagsall, and perlrebase intermingled
with system reboots until things work.

--Chris

 > 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

- Raw text -