Debugging help for fork failure: resource temporarily unavailable

[chm]

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