This is the mail archive of the
mailing list for the Cygwin project.
Re: Debugging help for fork failure: resource temporarily unavailable
- From: chm <devel dot chm dot 01 at gmail dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Cc: Ryan Johnson <ryanjohn at ece dot cmu dot edu>
- Date: Sun, 06 Mar 2011 09:41:19 -0500
- Subject: Re: Debugging help for fork failure: resource temporarily unavailable
- References: <4D72B5F2.email@example.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
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.
> 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?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple