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
