Mail Archives: cygwin/2011/03/07/10:10:50
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
- Raw text -