Debugging help for fork failure: resource temporarily unavailable

[Ryan Johnson <ryanjohn at ece dot cmu dot edu>]

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