From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12821 invoked by alias); 5 Mar 2011 22:17:18 -0000 Received: (qmail 12813 invoked by uid 22791); 5 Mar 2011 22:17:17 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from BACHE.ECE.CMU.EDU (HELO bache.ece.cmu.edu) (128.2.129.23) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Mar 2011 22:17:13 +0000 Received: from [192.168.0.101] (76-10-146-193.dsl.teksavvy.com [76.10.146.193]) by bache.ece.cmu.edu (Postfix) with ESMTP id 483B3C4 for ; Sat, 5 Mar 2011 17:17:11 -0500 (EST) Message-ID: <4D72B5F2.3090802@ece.cmu.edu> Date: Sat, 05 Mar 2011 22:17:00 -0000 From: Ryan Johnson 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@cygwin.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@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-03/txt/msg00187.txt.bz2 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