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
