Re: [PATCH] Prevent restart of crashing non-Cygwin exe
On Nov 2 20:53, Christian Franke wrote: > On Jun 24, Corinna Vinschen wrote: > >Hi Christian, > > > >On Jun 23 19:52, Christian Franke wrote: > >>If a non-Cygwin .exe started from a Cygwin shell window segfaults, > >>Cygwin restarts the .exe 5 times. > >>[...l] > >>* sigproc.cc (child_info::sync): Add exit_code to debug > >>message. > >>(child_info::proc_retry): Don't retry on unknown exit_code > >>from non-cygwin programs. > >This looks ok to me, but cgf should have a say here. He's on vacation > >for another week, though. > > > > Problem can still be reproduced with current CVS. Patch is still valid. Sorry, I forgot about this patch entirely. Chris, is that patch ok with you as well? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Extend faq.using to discuss fork failures
On 30/08/2011 14:41, Ryan Johnson wrote: That sounds reasonable, though I suspect we'd want want to keep the concluding bits in the FAQ as well. Unfortunately, summertime free time has come to an end so I don't know when I'll get to this next. Perhaps a good compromise for now would be for you to post only the first FAQ question? That would at least cut traffic to the cygwin ML a bit. I've updated Ryan's patch to hopefully address the comments made, polished the language a bit in places, and split it into a patch for the FAQ which just says how to fix problems and a patch for the UG which contains the technical details. Index: doc/faq-using.xml === RCS file: /cvs/src/src/winsup/doc/faq-using.xml,v retrieving revision 1.35 diff -u -p -r1.35 faq-using.xml --- doc/faq-using.xml 4 Aug 2011 18:25:41 - 1.35 +++ doc/faq-using.xml 3 Nov 2011 16:26:56 - @@ -1099,7 +1099,7 @@ it. IPv6 stack, see the http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx";>Microsoft TechNet IPv6 FAQ article - + What applications have been found to interfere with Cygwin? @@ -1199,3 +1199,38 @@ such as virtual memory paging and file c + + + How do I fix fork() failures? + + Unfortunately, Windows can be quite hostile to a + reliable fork() implementation, leading 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 http://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process";> + process creation section of the User's Guide for the technical reasons it is so + difficult to make fork() work reliably. + + Index: doc/overview2.sgml === RCS file: /cvs/src/src/winsup/doc/overview2.sgml,v retrieving revision 1.20 diff -u -p -r1.20 overview2.sgml --- doc/overview2.sgml 18 Sep 2010 15:58:46 - 1.20 +++ doc/overview2.sgml 3 Nov 2011 16:27:36 - @@ -346,6 +346,60 @@ cases, stubs of each of these Win32 proc 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). In a 64-bit system, marking +executables as large address-ware and rebasing dlls to high +addresses has been reported to help, as ASLR affects only the +lower 2GB of address space. + +DLL injection by +http://cygwin.com/faq/faq.using.html#faq.using.bloda";> +BLODA. Badly-behaved applications which +inject dlls into other processes often manage to clobber important +sections of the child's address space, leading to b
Re: Extend faq.using to discuss fork failures
Hi Jon, On Nov 3 16:35, Jon TURNEY wrote: > On 30/08/2011 14:41, Ryan Johnson wrote: > >That sounds reasonable, though I suspect we'd want want to keep the > >concluding > >bits in the FAQ as well. Unfortunately, summertime free time has come to an > >end so I don't know when I'll get to this next. Perhaps a good compromise for > >now would be for you to post only the first FAQ question? That would at least > >cut traffic to the cygwin ML a bit. > > I've updated Ryan's patch to hopefully address the comments made, > polished the language a bit in places, and split it into a patch for > the FAQ which just says how to fix problems and a patch for the UG > which contains the technical details. Thanks for doing that. I looks good to me, with just one exception. > +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). In a 64-bit system, marking > +executables as large address-ware and rebasing dlls to high > +addresses has been reported to help, as ASLR affects only the > +lower 2GB of address space. Starting with "In a 64-bit system" it's getting a bit weird: - Starting with 4.5.3, gcc marks executables as large address aware automatically, so this is going to be a lesser problem over time. Is it worth to mention this at all? I suppose so, but the user should be pointed to peflags to tests for this property first for the given reason. - Starting with Cygwin 1.7.10, the high address area will be used for the application heap on 64 bit systems and large address aware executables. Mmaps are located there, too. This in turn leaves more room for DLLs in the normal 2 Gigs memory area. Therefore I would not like to suggest rebasing DLLs into the high address area at all. This should only be done by people who know what they are doing. Usually there should be enough space in the lower 2 Gigs, especially when heap and mmaps are out of the way, and given that the more recent rebaseall will not create an arbitrary 64K hole between DLLs anymore when rebasing. With these changes, feel free to check in the patch. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Extend faq.using to discuss fork failures
On Thu, Nov 03, 2011 at 04:35:25PM +, Jon TURNEY wrote: >On 30/08/2011 14:41, Ryan Johnson wrote: >> That sounds reasonable, though I suspect we'd want want to keep the >> concluding >> bits in the FAQ as well. Unfortunately, summertime free time has come to an >> end so I don't know when I'll get to this next. Perhaps a good compromise for >> now would be for you to post only the first FAQ question? That would at least >> cut traffic to the cygwin ML a bit. > >I've updated Ryan's patch to hopefully address the comments made, polished the >language a bit in places, and split it into a patch for the FAQ which just >says how to fix problems and a patch for the UG which contains the technical >details. >Index: doc/faq-using.xml >=== >RCS file: /cvs/src/src/winsup/doc/faq-using.xml,v >retrieving revision 1.35 >diff -u -p -r1.35 faq-using.xml >--- doc/faq-using.xml 4 Aug 2011 18:25:41 - 1.35 >+++ doc/faq-using.xml 3 Nov 2011 16:26:56 - >@@ -1099,7 +1099,7 @@ it. > IPv6 stack, see the url="http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx";>Microsoft > TechNet IPv6 FAQ article > > >- >+ > What applications have been found to interfere with > Cygwin? > > >@@ -1199,3 +1199,38 @@ such as virtual memory paging and file c > > > >+ >+ >+ How do I fix fork() >failures? >+ >+ Unfortunately, Windows can be quite hostile to a I would still prefer eschewing actively negative words like "hostile" and just neutrally stating that Windows does not use a fork/exec model and does not offer any easy way to implement fork. I'd also like to see specific errors mentioned so that when people are searching for a solution to the problem they will be able to find it in the FAQ. cgf
Re: [PATCH] Prevent restart of crashing non-Cygwin exe
On Thu, Nov 03, 2011 at 01:07:20PM +0100, Corinna Vinschen wrote: >On Nov 2 20:53, Christian Franke wrote: >> On Jun 24, Corinna Vinschen wrote: >> >Hi Christian, >> > >> >On Jun 23 19:52, Christian Franke wrote: >> >>If a non-Cygwin .exe started from a Cygwin shell window segfaults, >> >>Cygwin restarts the .exe 5 times. >> >>[...l] >> >> * sigproc.cc (child_info::sync): Add exit_code to debug >> >> message. >> >> (child_info::proc_retry): Don't retry on unknown exit_code >> >> from non-cygwin programs. >> >This looks ok to me, but cgf should have a say here. He's on vacation >> >for another week, though. >> > >> >>Problem can still be reproduced with current CVS. Patch is still >>valid. > >Sorry, I forgot about this patch entirely. Chris, is that patch ok >with you as well? No, it isn't. Sorry for not stating this earlier. The problem that this code was intended to solve was actually a transient exit codes from a non-Cygwin process which began with 0xc... I don't believe that I ever saw STATUS_ACCESS_VIOLATION in any of my testing though so adding that earlier in the switch would fix this particular problem. I'll do that. cgf
