Re: Debugging help for fork failure: resource temporarily unavailable

[chm <devel dot chm dot 01 at gmail 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