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).
Actually, a follow-up question: what is the difference between the fork
(e.g. resource unavailable) failures vs. the errors about 'failed to
remap dll ...' ? Looking at the code in dll_init.cc, if failure to remap
a dll were really the source of fork failing, the error message should
say so. Is there some other issue due to BLODA that also causes forks to
fail?
Also, how does the (new?) peflagsall script interact with dll injection?
It sounds like it's supposed to fix dll remapping problems on machines
which support ASLR...
Thanks,
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
