Re: Debugging help for fork failure: resource temporarily unavailable

[Corinna Vinschen <corinna-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