diff --git a/winsup/doc/ChangeLog b/winsup/doc/ChangeLog index 81b1fa6c6..ec133f757 100644 --- a/winsup/doc/ChangeLog +++ b/winsup/doc/ChangeLog @@ -1,3 +1,9 @@ +2011-11-05 Jon TURNEY + + * faq-using.xml (faq.using.fixing-fork-failures): Add new FAQ. + * overview2.sgml (ov-hi-process-problems): Describe some difficulties + in implementing fork() + 2011-10-28 Corinna Vinschen * new-features.sgml (ov-new1.7.10): Document getgrouplist. diff --git a/winsup/doc/faq-using.xml b/winsup/doc/faq-using.xml index 7a09e2697..27f77837f 100644 --- a/winsup/doc/faq-using.xml +++ b/winsup/doc/faq-using.xml @@ -1099,7 +1099,7 @@ it. IPv6 stack, see the Microsoft TechNet IPv6 FAQ article - + What applications have been found to interfere with Cygwin? @@ -1199,3 +1199,39 @@ such as virtual memory paging and file caching. + + + How do I fix fork() failures? + + Unfortunately, Windows does not use the fork/exec model of process creation + found in UNIX-like OSes, so it is difficult for Cygwin to implement a reliable and + correct fork(), which can lead to error messages such as: + + unable to remap somedll to same address as parent + couldn't allocate heap + died waiting for dll loading + child -1 - died waiting for longjmp before initialization + STATUS_ACCESS_VIOLATION + resource temporarily unavailable + + Potential solutions for the above errors: + + Restart whatever process is trying (and failing) to use + fork(). Sometimes Windows sets up a process + environment that is even more hostile to fork() than usual. + Ensure that you have eliminated (not just disabled) all + software on the . + + Read the 'rebase' package README in + /usr/share/doc/rebase/, and follow the + instructions there to run 'rebaseall'. + + Please note that installing new packages or updating existing + ones undoes the effects of rebaseall and often causes fork() failures + to reappear. If so, just run rebaseall again. + + See the + process creation section of the User's Guide for the technical reasons it is so + difficult to make fork() work reliably. + + diff --git a/winsup/doc/overview2.sgml b/winsup/doc/overview2.sgml index 9e968f72f..5c1e8652f 100644 --- a/winsup/doc/overview2.sgml +++ b/winsup/doc/overview2.sgml @@ -346,6 +346,57 @@ cases, stubs of each of these Win32 processes may linger, waiting for their exec'd Cygwin process to exit. + +Problems with process creation + +The semantics of fork require that a forked +child process have exactly the same address +space layout as its parent. However, Windows provides no native +support for cloning address space between processes and several +features actively undermine a reliable fork +implementation. Three issues are especially prevalent: + + +DLL base address collisions. Unlike *nix shared +libraries, which use "position-independent code", Windows shared +libraries assume a fixed base address. Whenever the hard-wired +address ranges of two DLLs collide (which occurs quite often), the +Windows loader must "rebase" one of them to a different +address. However, it may not resolve collisions consistently, and +may rebase a different dll and/or move it to a different address +every time. Cygwin can usually compensate for this effect when it +involves libraries opened dynamically, but collisions among +statically-linked dlls (dependencies known at compile time) are +resolved before cygwin1.dll initializes and +cannot be fixed afterward. This problem can only be solved by +removing the base address conflicts which cause the problem, +usually using the rebaseall tool. + +Address space layout randomization (ASLR). Starting with +Vista, Windows implements ASLR, which means that thread stacks, +heap, memory-mapped files, and statically-linked dlls are placed +at different (random) locations in each process. This behaviour +interferes with a proper fork, and if an +unmovable object (process heap or system dll) ends up at the wrong +location, Cygwin can do nothing to compensate (though it will +retry a few times automatically). + +DLL injection by + +BLODA. Badly-behaved applications which +inject dlls into other processes often manage to clobber important +sections of the child's address space, leading to base address +collisions which rebasing cannot fix. The only way to resolve this +problem is to remove (usually uninstall) the offending +app. + +In summary, current Windows implementations make it +impossible to implement a perfectly reliable fork, and occasional +fork failures are inevitable. + + + + Signals When a Cygwin process starts, the library starts a secondary thread for