delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2011/03/09/05:23:27

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 9 Mar 2011 11:22:57 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Debugging help for fork failure: resource temporarily unavailable
Message-ID: <20110309102257.GN12899@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4D72B5F2 DOT 3090802 AT ece DOT cmu DOT edu>
MIME-Version: 1.0
In-Reply-To: <4D72B5F2.3090802@ece.cmu.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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 Mar  5 17:15, Ryan Johnson wrote:
> 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.

It's not that easy.  LD_PRELOAD is only honored after the other
stuff to duplicate the parent process has already taken place.

This is definitely not something for 1.7.9, but maybe we can utilize
the functionality we already have on board at one point.  In
fhandler_process.cc we have the function format_process_maps(), which
creates a buffer with the content of /proc/$PID/maps.  It might be
possible to call this function from fork for parent and child if fork
fails for this reason, and print this information.

Just an idea.  Somebody still would have to do it(*).


Corinna


(*) http://cygwin.com/contrib.html


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019